Re: [RT] a simple release plan
Jean-Baptiste Quenot wrote: * Vadim Gritsenko: http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b So IIUC you setup automated tests that were stopped since more than one year? I don't remember the decision to stop them. Since it generated no interest there were no reason to keep them running. Vadim
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: You said; libraries that are currently hosted on cvs.a.o, meaning they exist on cvs.a.o, and can't you just tell Maven in your pom to use that repository as well?? I meant : libraries that are currently hosted on cvs.a.o AND that are not hosted on ibiblio AND that we are dependent on Join the [EMAIL PROTECTED] mailing for discussion and more info. IIUIC, the http://cvs.apache.org/maven-snapshot-repository is meant for making snapshots available cross-ASF projects. I'm already on it, i'll continue argueing my case over there :) Jorg
Re: [RT] a simple release plan
Gianugo Rabellino wrote: http://tinyurl.com/s66vt Just change to suspend=n and you should be ready to go! Yes, that works great - thanks! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] a simple release plan
Carsten Ziegeler wrote: Ok, you're right (of course): the hierarchy of bean factories is correctly initialized, including for example the jx generator. For some strange reason, the tree processor of a sub sitemap is creating the correct bean factory but using the root bean factory. Therefore the jx generator can't be found. Ok, this is fixed now - I also updated the spring sample. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] a simple release plan
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: Didn't work for me. I copied configuration files and samples as described in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2 and still gets the same problem as Ben reports in the link above. I.e. that components are not inherited properly to subsitemaps. Stack trace below. Ok, you're right (of course): the hierarchy of bean factories is correctly initialized, including for example the jx generator. For some strange reason, the tree processor of a sub sitemap is creating the correct bean factory but using the root bean factory. Therefore the jx generator can't be found. What's the easiest way to debug the code? Can I easily run jetty in debug mode? I do most development in Eclipse and use the Jetty plugin (see http://marc.theaimsgroup.com/?t=11371588818r=1w=2 about setup), the Jetty plugin works fine with debugging. During development of the blocks fw I have used ServletUnit and tests at the functional level. So during most of the debugging I have started the main servlet from ServletUnit instead. The base test class can be found here http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-servlet-impl/src/test/java/org/apache/cocoon/ServletTestCase.java, and an example of using it here http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-servlet-impl/src/test/java/org/apache/cocoon/blocks/servlet/BlocksManagerTestCase.java, it will use a webapp in the same package, http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-blocks-fw/cocoon-blocks-fw-servlet-impl/src/test/resources/org/apache/cocoon/blocks/servlet/. The testing system is quite primitive but has been very useful despite that. We could move the base class to core (and maybe even make it less primitive and combine it with the HtmlUnit tests from 2.1.x), if others are interested. /Daniel
Re: [RT] a simple release plan
On 3/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: Daniel Fagerstrom wrote: Didn't work for me. I copied configuration files and samples as described in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2 and still gets the same problem as Ben reports in the link above. I.e. that components are not inherited properly to subsitemaps. Stack trace below. Ok, you're right (of course): the hierarchy of bean factories is correctly initialized, including for example the jx generator. For some strange reason, the tree processor of a sub sitemap is creating the correct bean factory but using the root bean factory. Therefore the jx generator can't be found. What's the easiest way to debug the code? Can I easily run jetty in debug mode? http://tinyurl.com/s66vt Just change to suspend=n and you should be ready to go! Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] a simple release plan
* Vadim Gritsenko: Carsten Ziegeler wrote: Reinhard Poetz schrieb: If a testcase gets broken *locally* by a developer, the developer should discuss the change on [EMAIL PROTECTED] and then people can decide together how to proceed. That should be the standard procedure in every development project, may it be opensource or commercial. Can we agree on these very basic rules? Some of our test cases are already broken for a long time; so it's hard to tell if for example my new changes broke something or if the test was already broken; currently I think our tests are not really used. http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b So IIUC you setup automated tests that were stopped since more than one year? I don't remember the decision to stop them. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. ... You can point your pom to use the cvs.a.o directly. What do you mean here? - the dependency is not available on the central m2 repo (the number of these libs is slowly declining due to better m2 acceptance) If it is not on the central repo, it is a non-released version and questionable that anyone should depend on it. best practice #1 - the dependency is available, but has a dodgy pom making it difficult to benefit from m2 features (eg transitive dependencies). Since you will need to manually clean this up here, perhaps sending the file over to the Maven peeps is collectively a better idea. best practice #2, we will do this ofcourse. - we're using a snapshot dependency that is not hosted anywhere else (remember the central repo only allows _released_ versions) IMHO, a questionable practice. (see below) indeed it is. Remember that this mirror would become only a *temporary* solution for any dependend library that has not fully mavenized yet. Now think again; After you have done this, and decommissioned the temporary solution, you are in a position of a non-working slot in time for that source. This goes both for SNAPSHOTs (which are actively being removed from their temporary storage spaces) and temporary artifact hosts. I'll classify this as a worry about it later. We haven't even released anything so this is no time to worry about 100% reproducible builds. I just want to make the maven build to reliably work using the quickest way possible. Anything that involves send something to someone else and wait until... is just not working for us at the moment. Regards Jorg
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Pier Fumagalli wrote: On 20 Mar 2006, at 09:19, Andrew Savory wrote: Hi, Jorg Heymans wrote: If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those lib in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? Pier http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110571714621160 Is something better now? I guess not. :-( /me looking for xerces-2.8.0 commons-io 1.2, et al in the maven2 repos. Best Regards, Antonio Gallardo.
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: If SNAPSHOTs are totally unavoidable, consider putting these in the Svn alongside the source code. Inability to build from today's source in the future is a serious flaw in chosen strategy. This is exactly what we do internally. ;-) Best Regards, Antonio Gallardo. Cheers Niclas
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On Wednesday 22 March 2006 01:00, Jorg Heymans wrote: Niclas Hedhman wrote: What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. ... You can point your pom to use the cvs.a.o directly. What do you mean here? You said; libraries that are currently hosted on cvs.a.o, meaning they exist on cvs.a.o, and can't you just tell Maven in your pom to use that repository as well?? Join the [EMAIL PROTECTED] mailing for discussion and more info. IIUIC, the http://cvs.apache.org/maven-snapshot-repository is meant for making snapshots available cross-ASF projects. I still maintain that checking in the libs to SVN are much more comfortable than a dependency on a temporary server. Cheers Niclas
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Niclas Hedhman wrote: You said; libraries that are currently hosted on cvs.a.o, meaning they exist on cvs.a.o, and can't you just tell Maven in your pom to use that repository as well?? From what I can see the build is set up to do that. The builds fail because apparently that repository can't handle the load. That is why we need a mirrored server. Cheers Niclas
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Hi, Jorg Heymans wrote: If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On 20 Mar 2006, at 09:19, Andrew Savory wrote: Hi, Jorg Heymans wrote: If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those lib in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? Pier smime.p7s Description: S/MIME cryptographic signature
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Hi, Pier Fumagalli wrote: Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those lib in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? Heh. Yes, the idea is that by going the maven route we can more easily use external libs without having to keep them all within Cocoon itself. Unfortunately, there's some scaling issues, so this has backfired on us: it's not that we don't like the existing maven repos, but that they have capacity issues right now which reflects badly on Cocoon. To people new to maven, it looks like Cocoon doesn't build even though it's maven unable to fetch from the repositories. So my suggestion was, since we have bandwidth to spare, we could provide a Cocoon-specific mirror as a short-term fix whilst the more general infrastructure problems are resolved. Actually, in hindsight, it makes more sense to see what can be done to fix maven's repo infrastructure - but I know nothing about ibiblio etc. and don't have time to investigate right now, so it's easier for me to simply say here's a machine with a ton of bandwidth, let's use that for now. If anyone knows how to do this in a more integrated way, please shout! Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Andrew Savory wrote: We (Luminas/SourceSense) are offering. Do you know what sort of requirements in terms of bandwidth and server space? We have capacity to spare, and are happy to donate it. Thanks, see below. Pier Fumagalli wrote: Excuse me, but can someone refresh my memory on why we went down the Maven way? I thought it was to get rid of maintaining all those lib in our SVN, and now someone is telling me that we actually should maintain a full maven mirror, but tweaked because we don't like theirs? My mistake, i should've explained things a bit more. What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. There are various reasons why we decided to host some of our dependencies there: - the dependency is not available on the central m2 repo (the number of these libs is slowly declining due to better m2 acceptance) - the dependency is available, but has a dodgy pom making it difficult to benefit from m2 features (eg transitive dependencies). - we're using a snapshot dependency that is not hosted anywhere else (remember the central repo only allows _released_ versions) Remember that this mirror would become only a *temporary* solution for any dependend library that has not fully mavenized yet. We should still practice maven evangelism and encourage the library owners to mavenize and release code to the central repo. I'll compile a report of what we're currently pulling from cvs.a.o., this should make it easier to estimate required bandwidth. In any case I will speak to Brett or Jason to see how they feel about this. Hope this clears things up a bit, Jorg
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Andrew Savory wrote: infrastructure problems are resolved. Actually, in hindsight, it makes more sense to see what can be done to fix maven's repo infrastructure - but I know nothing about ibiblio etc. and don't have time to investigate This is being worked on by maven and infra, but it's a slooow process. right now, so it's easier for me to simply say here's a machine with a ton of bandwidth, let's use that for now. Yes that's the easiest and most rewarding way to go for now. Here is a list of dependencies that are currently pulled from cvs.a.o/repository or cvs.a.o/maven-snapshot-repository. I didn't have time to lookup and add sizes together but it doesn't look like more than 30-40MB .. (ignore the numbers, they're from subsequent maven runs) 1) jakarta-bcel:jakarta-bcel:jar:20040329 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) jakarta-bcel:jakarta-bcel:jar:20040329 2) org.apache.excalibur.components.store:excalibur-store:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.store:excalibur-store:jar:2.1 3) org.apache.avalon.framework:avalon-framework-impl:jar:4.3 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.avalon.framework:avalon-framework-impl:jar:4.3 4) org.apache.excalibur.components.sourceresolve:excalibur-sourceresolve:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.sourceresolve:excalibur-sourceresolve:jar:2.1 5) org.apache.excalibur.containerkit.logger:excalibur-logger:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.containerkit.logger:excalibur-logger:jar:2.1 6) org.apache.excalibur.components.pool:excalibur-pool-impl:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.pool:excalibur-pool-impl:jar:2.1 7) commons-jci:commons-jci:jar:r306555 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) commons-jci:commons-jci:jar:r306555 8) commons-javaflow:commons-javaflow:jar:r306555 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) commons-javaflow:commons-javaflow:jar:r306555 9) org.apache.excalibur.components.xmlutil:excalibur-xmlutil:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.xmlutil:excalibur-xmlutil:jar:2.1 10) org.apache.excalibur.containerkit.instrument:excalibur-instrument-api:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.containerkit.instrument:excalibur-instrument-api:jar:2.1 11) org.apache.excalibur.components.pool:excalibur-pool-instrumented:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.pool:excalibur-pool-instrumented:jar:2.1 1) org.apache.excalibur.components.sourceresolve:excalibur-sourceresolve:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.sourceresolve:excalibur-sourceresolve:jar:2.1 2) org.apache.excalibur.components.store:excalibur-store:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.store:excalibur-store:jar:2.1 3) org.apache.excalibur.containerkit.logger:excalibur-logger:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.containerkit.logger:excalibur-logger:jar:2.1 4) org.apache.avalon.framework:avalon-framework-impl:jar:4.3 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.avalon.framework:avalon-framework-impl:jar:4.3 5) org.apache.excalibur.components.pool:excalibur-pool-instrumented:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.pool:excalibur-pool-instrumented:jar:2.1 6) org.apache.excalibur.components.pool:excalibur-pool-impl:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.components.pool:excalibur-pool-impl:jar:2.1 7) org.apache.excalibur.containerkit.instrument:excalibur-instrument-api:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2) org.apache.excalibur.containerkit.instrument:excalibur-instrument-api:jar:2.1 8) org.apache.excalibur.components.xmlutil:excalibur-xmlutil:jar:2.1 Path to dependency: 1) org.apache.cocoon:cocoon-core:jar:2.2.0-SNAPSHOT 2)
Re: setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
On Tuesday 21 March 2006 02:32, Jorg Heymans wrote: What is being suggested is not that we mirror the whole of ibiblio, we would only mirror the libraries that are currently hosted on cvs.a.o. This sounds like a really odd idea. You can point your pom to use the cvs.a.o directly. - the dependency is not available on the central m2 repo (the number of these libs is slowly declining due to better m2 acceptance) If it is not on the central repo, it is a non-released version and questionable that anyone should depend on it. - the dependency is available, but has a dodgy pom making it difficult to benefit from m2 features (eg transitive dependencies). Since you will need to manually clean this up here, perhaps sending the file over to the Maven peeps is collectively a better idea. - we're using a snapshot dependency that is not hosted anywhere else (remember the central repo only allows _released_ versions) IMHO, a questionable practice. (see below) Remember that this mirror would become only a *temporary* solution for any dependend library that has not fully mavenized yet. Now think again; After you have done this, and decommissioned the temporary solution, you are in a position of a non-working slot in time for that source. This goes both for SNAPSHOTs (which are actively being removed from their temporary storage spaces) and temporary artifact hosts. If SNAPSHOTs are totally unavoidable, consider putting these in the Svn alongside the source code. Inability to build from today's source in the future is a serious flaw in chosen strategy. Cheers Niclas
Re: [RT] a simple release plan
Daniel Fagerstrom wrote: Didn't work for me. I copied configuration files and samples as described in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2 and still gets the same problem as Ben reports in the link above. I.e. that components are not inherited properly to subsitemaps. Stack trace below. Ok, you're right (of course): the hierarchy of bean factories is correctly initialized, including for example the jx generator. For some strange reason, the tree processor of a sub sitemap is creating the correct bean factory but using the root bean factory. Therefore the jx generator can't be found. What's the easiest way to debug the code? Can I easily run jetty in debug mode? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] a simple release plan
Carsten Ziegeler skrev: Daniel Fagerstrom schrieb: Carsten Ziegeler skrev: I'm sorry if I broke something in trunk with the move to Spring or the refactoring; I'm currently not aware of a problem as trunk is working for me here on my machine. So if someone can come up with a bug description or stack trace I can try to fix that (if time permits). For a fresh checkout and a clean compile of trunk: $ cd cocoon-webapp $ mvn jetty6:run Any call to a subsitemap e.g. http://localhost:/cocoon-webapp/samples/spring/test leads to an NPE, the problems seem to be with calling subsitemaps as non existing URLs for subsitemaps gives the same error. Stack trace below. The same problems has been reported before in a different context http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114175709422729w=2. This should be fixed now; the current tree builder/container generation code is now rather ugly and definitly needs some clean up. I can help there as soon as I have time. Thanks, it works for me also. There also have been a problem with subsitemap inheritance of components, that I don't know if it is solved yet: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114090981108642w=2 It should be, but could not test yet. Didn't work for me. I copied configuration files and samples as described in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2 and still gets the same problem as Ben reports in the link above. I.e. that components are not inherited properly to subsitemaps. Stack trace below. The test cases for blocks fw are also still broken. I will take a look at that part as soon as I find time. /Daniel org.apache.cocoon.ProcessingException: Sitemap: error when calling sub-sitemap at [ConfigurationException] - file:/C:/cygwin/usr/local/svn/cocoon-trunk/cocoon-samples-webapp/src/main/webapp/samples/blocks/forms/sitemap.xmap:126:72 at map:mount - file:/C:/cygwin/usr/local/svn/cocoon-trunk/cocoon-samples-webapp/src/main/webapp/samples/blocks/sitemap.xmap:78:49 at map:mount - file:/C:/cygwin/usr/local/svn/cocoon-trunk/cocoon-samples-webapp/src/main/webapp/samples/sitemap.xmap:36:49 at map:mount - file:/C:/cygwin/usr/local/svn/cocoon-trunk/cocoon-samples-webapp/src/main/webapp/sitemap.xmap:274:47 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:110) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:116) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:54) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:115) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:91) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:329) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:228) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:249) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:113) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:54) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:115) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:91) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:329) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:228) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:249) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:113) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:54) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:115) at
Re: [RT] a simple release plan
Carsten Ziegeler skrev: I'm sorry if I broke something in trunk with the move to Spring or the refactoring; I'm currently not aware of a problem as trunk is working for me here on my machine. So if someone can come up with a bug description or stack trace I can try to fix that (if time permits). For a fresh checkout and a clean compile of trunk: $ cd cocoon-webapp $ mvn jetty6:run Any call to a subsitemap e.g. http://localhost:/cocoon-webapp/samples/spring/test leads to an NPE, the problems seem to be with calling subsitemaps as non existing URLs for subsitemaps gives the same error. Stack trace below. The same problems has been reported before in a different context http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114175709422729w=2. There also have been a problem with subsitemap inheritance of components, that I don't know if it is solved yet: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114090981108642w=2 Apart from that, I'll stop talking about this release plan. Thank you Carsten, I appreciate that. /Daniel org.apache.cocoon.ProcessingException: Sitemap: error when calling sub-sitemap at map:mount - file:/C:/cygwin/usr/local/svn/cocoon-trunk/cocoon-webapp/src/main/webapp/sitemap.xmap:274:47 at org.apache.cocoon.ProcessingException.throwLocated(ProcessingException.java:110) at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:116) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:54) at org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:115) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:150) at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:76) at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:91) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:329) at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:228) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:248) at org.apache.cocoon.Cocoon.process(Cocoon.java:232) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:281) at javax.servlet.http.HttpServlet.service(HttpServlet.java:860) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:423) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:350) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:195) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:164) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:536) at org.mortbay.jetty.Server.handle(Server.java:309) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.doHandler(HttpConnection.java:364) at org.mortbay.jetty.HttpConnection.access$1600(HttpConnection.java:46) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:612) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:485) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:194) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:298) at org.mortbay.jetty.nio.SelectChannelConnector$HttpEndPoint.run(SelectChannelConnector.java:710) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:412) Caused by: org.apache.avalon.framework.configuration.ConfigurationException: Could not load TreeBuilder configuration from resource://org/apache/cocoon/components/treeprocessor/sitemap-language.xml at org.apache.cocoon.components.treeprocessor.sitemap.SitemapLanguage.build(SitemapLanguage.java:423) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.cocoon.core.container.spring.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:339) at $Proxy1.build(Unknown Source) at org.apache.cocoon.components.treeprocessor.TreeProcessor.buildConcreteProcessor(TreeProcessor.java:411) at org.apache.cocoon.components.treeprocessor.TreeProcessor.setupConcreteProcessor(TreeProcessor.java:346) at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:247) at
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Upayavira schrieb: Andreas Hochsteger wrote: I successfully built cocoon-linkrewriter using 'mvn package' with the converted directory structure using the conversion script and 2 new and one adopted pom file. I wanted to attach them, but for some reasons my SMTP server rejected them as SPAM. :-( I used the following conventions for the block poms: * version: 1.0-SNAPSHOT * sample depends only on impl * impl depends on cocoon-core (and other direct dependencies) - based on the existing pom of the old block * parent declares sample and impl as modules Could somebody please have a look at the attached poms? I'll try to extend the script to generate the parent and sample poms automatically and adjust the impl pom (based on the old block pom). Create a jira issue and attach any files relating to this work to that issue. Done. See http://issues.apache.org/jira/browse/COCOON-1802 It supports the creation of the poms too and uses the maven archetype for cocoon as suggested in http://cocoon.zones.apache.org/daisy/documentation/863/g1/796.html The implementation pom has still to be merged manually with the old pom. See README.txt in the ZIP file or the Jire Issue description for more details. You're doing good work. Thanks :-) Regards, Upayavira Andreas
setting up a Cocoon m2 repo mirror (was Re: [RT] a simple release plan)
Andrew Savory wrote: Is there any way we can set up a Cocoon mirror for the time being, until the repository problems are resolved? I'm sure several of us here can set up a repo, and it could be the default used by Cocoon. If someone can offer the bandwidth and server, i'm willing to migrate us away from cvs.a.o. and setup a decent m2 repo where only *we* control the poms. Any offers? I've got some time to kill this weekend ;) Regards Jorg
Re: [RT] a simple release plan
Daniel Fagerstrom wrote: It would also be very valuable if someone with Cocoon zones competence could get the snapshot build running again (http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/). With the snapshots working one just need to check out the blocks that one actually want to develop. I'll take care of this. Jorg
Re: [RT] a simple release plan
Daniel Fagerstrom schrieb: Carsten Ziegeler skrev: I'm sorry if I broke something in trunk with the move to Spring or the refactoring; I'm currently not aware of a problem as trunk is working for me here on my machine. So if someone can come up with a bug description or stack trace I can try to fix that (if time permits). For a fresh checkout and a clean compile of trunk: $ cd cocoon-webapp $ mvn jetty6:run Any call to a subsitemap e.g. http://localhost:/cocoon-webapp/samples/spring/test leads to an NPE, the problems seem to be with calling subsitemaps as non existing URLs for subsitemaps gives the same error. Stack trace below. The same problems has been reported before in a different context http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114175709422729w=2. This should be fixed now; the current tree builder/container generation code is now rather ugly and definitly needs some clean up. I can help there as soon as I have time. There also have been a problem with subsitemap inheritance of components, that I don't know if it is solved yet: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114090981108642w=2 It should be, but could not test yet. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] a simple release plan
I'm sorry if I broke something in trunk with the move to Spring or the refactoring; I'm currently not aware of a problem as trunk is working for me here on my machine. So if someone can come up with a bug description or stack trace I can try to fix that (if time permits). Apart from that, I'll stop talking about this release plan. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] a simple release plan
Daniel Fagerstrom wrote: Ralph Goers skrev: Andrew Savory wrote: Hi, Ralph Goers wrote: 1. I'm pretty sure all the blocks have not been mavenized. Is there a list of blocks to mavenise anywhere, with instructions of how to do it? I don't mind helping with this. The easy way to tell I suppose is to check out trunk. There are a bunch of cocoon-whatever directories. Compare that list with what is in src/blocks in 2.1. I believe the instructions are in README.m10n.txt. Actually all the trunk blocks http://svn.apache.org/repos/asf/cocoon/blocks/ was Mavenized once. Then two things happened: 1) We decided to change to change directory structure to something that followed the Maven standard, and that had some other advantages: http://cocoon.zones.apache.org/daisy/documentation/g1/756.html. All blocks with the new structure are moved to the trunk. 2) We changed group id from apache-cocoon to org.apache.cocoon (in trunk). As the later is the recomended structure for M2. Most of the blocks in http://svn.apache.org/repos/asf/cocoon/blocks/ would probably build again just by fixing the group id. It would of course be nice to switch all to the new directory structure, but that can be done one block at the time when someone feel the itch. Is there something that persons without SVN access can help with? The instructions for the m10n of Cocoon Blocks require SVN access for moving directories and files. Nevertheless I'd be glad to help by providing patches via Jira, if somebody could tell me what might be doable for me. I already was able to build the trunk with Maven and run the Welcome page - but without samples so far. [snip] /Daniel Thanks, Andreas
Re: [RT] a simple release plan
Andreas Hochsteger wrote: Daniel Fagerstrom wrote: Ralph Goers skrev: Andrew Savory wrote: Hi, Ralph Goers wrote: 1. I'm pretty sure all the blocks have not been mavenized. Is there a list of blocks to mavenise anywhere, with instructions of how to do it? I don't mind helping with this. The easy way to tell I suppose is to check out trunk. There are a bunch of cocoon-whatever directories. Compare that list with what is in src/blocks in 2.1. I believe the instructions are in README.m10n.txt. Actually all the trunk blocks http://svn.apache.org/repos/asf/cocoon/blocks/ was Mavenized once. Then two things happened: 1) We decided to change to change directory structure to something that followed the Maven standard, and that had some other advantages: http://cocoon.zones.apache.org/daisy/documentation/g1/756.html. All blocks with the new structure are moved to the trunk. 2) We changed group id from apache-cocoon to org.apache.cocoon (in trunk). As the later is the recomended structure for M2. Most of the blocks in http://svn.apache.org/repos/asf/cocoon/blocks/ would probably build again just by fixing the group id. It would of course be nice to switch all to the new directory structure, but that can be done one block at the time when someone feel the itch. Is there something that persons without SVN access can help with? The instructions for the m10n of Cocoon Blocks require SVN access for moving directories and files. Nevertheless I'd be glad to help by providing patches via Jira, if somebody could tell me what might be doable for me. I already was able to build the trunk with Maven and run the Welcome page - but without samples so far. The subversion part is the easiest bit. Working out exactly how to make it work is very useful and doesn't require SVN commit rights. Although, if you do move directories, try using svn move, as it will likely make for better svn patch or svn diff output at the end of the process. Personally, I would say go for it. Anything anyone can do would be great, and is much needed right now. Regards, Upayavira
Re: [RT] a simple release plan
Upayavira schrieb:
Andreas Hochsteger wrote:
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with this.
The easy way to tell I suppose is to check out trunk. There are a
bunch of cocoon-whatever directories. Compare that list with what is
in src/blocks in 2.1. I believe the instructions are in
README.m10n.txt.
Actually all the trunk blocks
http://svn.apache.org/repos/asf/cocoon/blocks/ was Mavenized once.
Then two things happened:
1) We decided to change to change directory structure to something
that followed the Maven standard, and that had some other advantages:
http://cocoon.zones.apache.org/daisy/documentation/g1/756.html. All
blocks with the new structure are moved to the trunk.
2) We changed group id from apache-cocoon to org.apache.cocoon (in
trunk). As the later is the recomended structure for M2.
Most of the blocks in http://svn.apache.org/repos/asf/cocoon/blocks/
would probably build again just by fixing the group id.
It would of course be nice to switch all to the new directory
structure, but that can be done one block at the time when someone
feel the itch.
Is there something that persons without SVN access can help with?
The instructions for the m10n of Cocoon Blocks require SVN access for
moving directories and files.
Nevertheless I'd be glad to help by providing patches via Jira, if
somebody could tell me what might be doable for me.
I already was able to build the trunk with Maven and run the Welcome
page - but without samples so far.
The subversion part is the easiest bit. Working out exactly how to make
it work is very useful and doesn't require SVN commit rights. Although,
if you do move directories, try using svn move, as it will likely make
for better svn patch or svn diff output at the end of the process.
Personally, I would say go for it. Anything anyone can do would be
great, and is much needed right now.
Thanks, Upayavira!
I mocked-up a shell script which converts the directories from the old
blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to do,
but at least some easy parts can be automated this way.
It handles the following directories from the old blocks:
* java
* test
* conf
* WEB-INF
* samples
Currently the directories are only copied and not moved via 'svn mv'.
I wrapped the commands for moving directories into the function
MoveDir() which can be adjusted to perform svn operations.
The converted directory structure looks like this (blockname refers to
the directory name of the old blocks):
cocoon-blockname
+-cocoon-blockname-impl
| +-src
| | +-main
| | | +-java ('java' from old blocks)
| | | +-resources
| | | | +-WEB-INF ('WEB-INF' from old blocks)
| | | | +-conf ('conf' from old blocks)
| | +-test
| | | +-java ('test' from old blocks)
| +-cocoon-blockname-sample
| +-src
| | +-main
| | | +-resources
| | | | +-samples ('samples' from old blocks)
It would be great if somebody can have a look at it, if I got everything
right.
Next step would be to adjust MoveDir() for svn operations and to handle
pom.xml.
I don't know if the handling of pom.xml can be easily automated, since
it has to be split into 3 pom files.
Regards, Upayavira
Thanks,
Andreas
#!/bin/sh
# Author: Andreas Hochsteger [EMAIL PROTECTED]
# Description:
# This script partly automates the conversion of the directory structure
# of the old blocks to the mavenized blocks.
# Usage: m10n-blocks.sh blockname...
# Local directory where https://svn.apache.org/repos/asf/cocoon/blocks is
checked out:
blksrc=cocoon-blocks
# Local directory where https://svn.apache.org/repos/asf/cocoon/trunk is
checked out:
blkdest=cocoon-trunk
# List of blocks (old name) to be converted - read from the command line:
blocks=$@
# Argument: from to
function MoveDir() {
if [ -d $1 ]; then
echo Moving $1 to $2 ...
# TODO: Replace with svn commands
mkdir -p `dirname $2`
cp -r $1 $2
fi
}
# Argument: blockname
function ConvertBlock() {
block=$1
blockbase=$blkdest/cocoon-$block
# Create initial directory structure:
mkdir -p $blockbase
# Move Java sources:
MoveDir $blksrc/$block/trunk/java
$blockbase/cocoon-$block-impl/src/main/java
# Move Java test sources:
MoveDir $blksrc/$block/trunk/test
$blockbase/cocoon-$block-impl/src/test/java
# Move WEB-INF resources:
MoveDir $blksrc/$block/trunk/WEB-INF
$blockbase/cocoon-$block-impl/src/main/resources/WEB-INF
# Move WEB-INF resources:
MoveDir $blksrc/$block/trunk/conf
$blockbase/cocoon-$block-impl/src/main/resources/conf
# Move sample resources:
MoveDir $blksrc/$block/trunk/samples
$blockbase/cocoon-$block-sample/src/main/resources/samples
}
# Convert the blocks:
for
Re: [RT] a simple release plan
Andreas Hochsteger wrote:
Upayavira schrieb:
Andreas Hochsteger wrote:
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with this.
The easy way to tell I suppose is to check out trunk. There are a
bunch of cocoon-whatever directories. Compare that list with what is
in src/blocks in 2.1. I believe the instructions are in
README.m10n.txt.
Actually all the trunk blocks
http://svn.apache.org/repos/asf/cocoon/blocks/ was Mavenized once.
Then two things happened:
1) We decided to change to change directory structure to something
that followed the Maven standard, and that had some other advantages:
http://cocoon.zones.apache.org/daisy/documentation/g1/756.html. All
blocks with the new structure are moved to the trunk.
2) We changed group id from apache-cocoon to org.apache.cocoon (in
trunk). As the later is the recomended structure for M2.
Most of the blocks in http://svn.apache.org/repos/asf/cocoon/blocks/
would probably build again just by fixing the group id.
It would of course be nice to switch all to the new directory
structure, but that can be done one block at the time when someone
feel the itch.
Is there something that persons without SVN access can help with?
The instructions for the m10n of Cocoon Blocks require SVN access for
moving directories and files.
Nevertheless I'd be glad to help by providing patches via Jira, if
somebody could tell me what might be doable for me.
I already was able to build the trunk with Maven and run the Welcome
page - but without samples so far.
The subversion part is the easiest bit. Working out exactly how to make
it work is very useful and doesn't require SVN commit rights. Although,
if you do move directories, try using svn move, as it will likely make
for better svn patch or svn diff output at the end of the process.
Personally, I would say go for it. Anything anyone can do would be
great, and is much needed right now.
Thanks, Upayavira!
I mocked-up a shell script which converts the directories from the old
blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to do,
but at least some easy parts can be automated this way.
It handles the following directories from the old blocks:
* java
* test
* conf
* WEB-INF
* samples
Currently the directories are only copied and not moved via 'svn mv'.
I wrapped the commands for moving directories into the function
MoveDir() which can be adjusted to perform svn operations.
The converted directory structure looks like this (blockname refers to
the directory name of the old blocks):
cocoon-blockname
+-cocoon-blockname-impl
| +-src
| | +-main
| | | +-java ('java' from old blocks)
| | | +-resources
| | | | +-WEB-INF ('WEB-INF' from old blocks)
| | | | +-conf ('conf' from old blocks)
| | +-test
| | | +-java ('test' from old blocks)
| +-cocoon-blockname-sample
| +-src
| | +-main
| | | +-resources
| | | | +-samples ('samples' from old blocks)
It would be great if somebody can have a look at it, if I got everything
right.
Next step would be to adjust MoveDir() for svn operations and to handle
pom.xml.
I don't know if the handling of pom.xml can be easily automated, since
it has to be split into 3 pom files.
Andreas, thanks for getting involved! Your work looks good; could you please
make some changes to the directory structure of the new block? What we need is
a structure as used in cocoon-deployer-plugin-demo:
src
main
java
resources
COB-INF -- the webapp here (e.g. samples)
META-INF -- component configurations here
This is the right structure for real blocks. In order to satisfy our current
needs of deploying into a web application that does *not* use the blocks-fw, we
can extract the JAR into several places from within an Ant script or a Mojo:
COB-INF-- [web-app]/samples
META-INF -- [web-app]/WEB-INF/xconf
the JAR itself -- [web-app]/WEB-INF/lib
It shouldn't matter that we use the new structure.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Script for m10n of blocks (was Re: [RT] a simple release plan)
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to
do, but at least some easy parts can be automated this way.
It handles the following directories from the old blocks:
* java
* test
* conf
* WEB-INF
* samples
Currently the directories are only copied and not moved via 'svn mv'.
I wrapped the commands for moving directories into the function
MoveDir() which can be adjusted to perform svn operations.
The converted directory structure looks like this (blockname refers
to the directory name of the old blocks):
cocoon-blockname
+-cocoon-blockname-impl
| +-src
| | +-main
| | | +-java ('java' from old blocks)
| | | +-resources
| | | | +-WEB-INF ('WEB-INF' from old blocks)
| | | | +-conf ('conf' from old blocks)
| | +-test
| | | +-java ('test' from old blocks)
| +-cocoon-blockname-sample
| +-src
| | +-main
| | | +-resources
| | | | +-samples ('samples' from old blocks)
It would be great if somebody can have a look at it, if I got
everything right.
Next step would be to adjust MoveDir() for svn operations and to
handle pom.xml.
I don't know if the handling of pom.xml can be easily automated, since
it has to be split into 3 pom files.
Andreas, thanks for getting involved! Your work looks good; could you
please make some changes to the directory structure of the new block?
What we need is a structure as used in cocoon-deployer-plugin-demo:
src
main
java
resources
COB-INF -- the webapp here (e.g. samples)
META-INF -- component configurations here
This is the right structure for real blocks. In order to satisfy our
current needs of deploying into a web application that does *not* use
the blocks-fw, we can extract the JAR into several places from within an
Ant script or a Mojo:
COB-INF-- [web-app]/samples
META-INF -- [web-app]/WEB-INF/xconf
the JAR itself -- [web-app]/WEB-INF/lib
It shouldn't matter that we use the new structure.
Thanks for the hints.
Do I understand it right, if I put COB-INF between resources/samples and
META-INF between resources/conf and resources/WEB-INF.
The rest stays as I suggested it?
Andreas.
Re: [RT] a simple release plan
Carsten Ziegeler wrote: Reinhard Poetz schrieb: If a testcase gets broken *locally* by a developer, the developer should discuss the change on [EMAIL PROTECTED] and then people can decide together how to proceed. That should be the standard procedure in every development project, may it be opensource or commercial. Can we agree on these very basic rules? Some of our test cases are already broken for a long time; so it's hard to tell if for example my new changes broke something or if the test was already broken; currently I think our tests are not really used. http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b Vadim
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to
do, but at least some easy parts can be automated this way.
It handles the following directories from the old blocks:
* java
* test
* conf
* WEB-INF
* samples
Currently the directories are only copied and not moved via 'svn mv'.
I wrapped the commands for moving directories into the function
MoveDir() which can be adjusted to perform svn operations.
The converted directory structure looks like this (blockname refers
to the directory name of the old blocks):
cocoon-blockname
+-cocoon-blockname-impl
| +-src
| | +-main
| | | +-java ('java' from old blocks)
| | | +-resources
| | | | +-WEB-INF ('WEB-INF' from old blocks)
| | | | +-conf ('conf' from old blocks)
| | +-test
| | | +-java ('test' from old blocks)
| +-cocoon-blockname-sample
| +-src
| | +-main
| | | +-resources
| | | | +-samples ('samples' from old blocks)
It would be great if somebody can have a look at it, if I got
everything right.
Next step would be to adjust MoveDir() for svn operations and to
handle pom.xml.
I don't know if the handling of pom.xml can be easily automated,
since it has to be split into 3 pom files.
Andreas, thanks for getting involved! Your work looks good; could you
please make some changes to the directory structure of the new
block? What we need is a structure as used in
cocoon-deployer-plugin-demo:
src
main
java
resources
COB-INF -- the webapp here (e.g. samples)
META-INF -- component configurations here
This is the right structure for real blocks. In order to satisfy our
current needs of deploying into a web application that does *not* use
the blocks-fw, we can extract the JAR into several places from within
an Ant script or a Mojo:
COB-INF-- [web-app]/samples
META-INF -- [web-app]/WEB-INF/xconf
the JAR itself -- [web-app]/WEB-INF/lib
It shouldn't matter that we use the new structure.
Thanks for the hints.
Do I understand it right, if I put COB-INF between resources/samples and
META-INF between resources/conf and resources/WEB-INF.
The rest stays as I suggested it?
hmm, I don't understand what you mean with put between. The idea is that the
web application goes into COB-INF. Meta data and component configuration goes
into META-INF. There is no need for a resources/samples, resources/WEB-INF or
resources/conf directory.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] a simple release plan
Vadim Gritsenko wrote: http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b Nice statistics :) I was talking about the tests in trunk. Carsten
Re: [RT] a simple release plan
Carsten Ziegeler wrote: Vadim Gritsenko wrote: http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b Nice statistics :) I was talking about the tests in trunk. Well if tests are/were ignored in stable branch, why trunk would be any better? Vadim
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to
do, but at least some easy parts can be automated this way.
It handles the following directories from the old blocks:
* java
* test
* conf
* WEB-INF
* samples
Currently the directories are only copied and not moved via 'svn mv'.
I wrapped the commands for moving directories into the function
MoveDir() which can be adjusted to perform svn operations.
The converted directory structure looks like this (blockname
refers to the directory name of the old blocks):
cocoon-blockname
+-cocoon-blockname-impl
| +-src
| | +-main
| | | +-java ('java' from old blocks)
| | | +-resources
| | | | +-WEB-INF ('WEB-INF' from old blocks)
| | | | +-conf ('conf' from old blocks)
| | +-test
| | | +-java ('test' from old blocks)
| +-cocoon-blockname-sample
| +-src
| | +-main
| | | +-resources
| | | | +-samples ('samples' from old blocks)
It would be great if somebody can have a look at it, if I got
everything right.
Next step would be to adjust MoveDir() for svn operations and to
handle pom.xml.
I don't know if the handling of pom.xml can be easily automated,
since it has to be split into 3 pom files.
Andreas, thanks for getting involved! Your work looks good; could you
please make some changes to the directory structure of the new
block? What we need is a structure as used in
cocoon-deployer-plugin-demo:
src
main
java
resources
COB-INF -- the webapp here (e.g. samples)
META-INF -- component configurations here
This is the right structure for real blocks. In order to satisfy
our current needs of deploying into a web application that does *not*
use the blocks-fw, we can extract the JAR into several places from
within an Ant script or a Mojo:
COB-INF-- [web-app]/samples
META-INF -- [web-app]/WEB-INF/xconf
the JAR itself -- [web-app]/WEB-INF/lib
It shouldn't matter that we use the new structure.
Thanks for the hints.
Do I understand it right, if I put COB-INF between resources/samples
and META-INF between resources/conf and resources/WEB-INF.
The rest stays as I suggested it?
hmm, I don't understand what you mean with put between. The idea is
that the web application goes into COB-INF. Meta data and component
configuration goes into META-INF. There is no need for a
resources/samples, resources/WEB-INF or resources/conf directory.
With 'between' I meant .../resources/COB-INF/samples - sorry for my bad
phrasing.
But looking at cocoon-deployer-plugin-demo it looks more like the following:
samples - cocoon-block-sample/src/main/resources/COB-INF
WEB-INF/xconf - cocoon-block-impl/src/main/resources/META-INF/xconf(?)
conf - (? contain *.xweb, *.properties and other files)
I'm still uncertain about the last two directories.
Can you give me some more details (or pointers) which files and
directories from the old blocks map to the new ones?
Once I have this information I can adjust the script to respect this
information.
Thanks,
Andreas
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Andreas Hochsteger schrieb:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work
to do, but at least some easy parts can be automated this way.
It handles the following directories from the old blocks:
* java
* test
* conf
* WEB-INF
* samples
Currently the directories are only copied and not moved via 'svn mv'.
I wrapped the commands for moving directories into the function
MoveDir() which can be adjusted to perform svn operations.
The converted directory structure looks like this (blockname
refers to the directory name of the old blocks):
cocoon-blockname
+-cocoon-blockname-impl
| +-src
| | +-main
| | | +-java ('java' from old blocks)
| | | +-resources
| | | | +-WEB-INF ('WEB-INF' from old blocks)
| | | | +-conf ('conf' from old blocks)
| | +-test
| | | +-java ('test' from old blocks)
| +-cocoon-blockname-sample
| +-src
| | +-main
| | | +-resources
| | | | +-samples ('samples' from old blocks)
It would be great if somebody can have a look at it, if I got
everything right.
Next step would be to adjust MoveDir() for svn operations and to
handle pom.xml.
I don't know if the handling of pom.xml can be easily automated,
since it has to be split into 3 pom files.
Andreas, thanks for getting involved! Your work looks good; could
you please make some changes to the directory structure of the new
block? What we need is a structure as used in
cocoon-deployer-plugin-demo:
src
main
java
resources
COB-INF -- the webapp here (e.g. samples)
META-INF -- component configurations here
This is the right structure for real blocks. In order to satisfy
our current needs of deploying into a web application that does
*not* use the blocks-fw, we can extract the JAR into several places
from within an Ant script or a Mojo:
COB-INF-- [web-app]/samples
META-INF -- [web-app]/WEB-INF/xconf
the JAR itself -- [web-app]/WEB-INF/lib
It shouldn't matter that we use the new structure.
Thanks for the hints.
Do I understand it right, if I put COB-INF between resources/samples
and META-INF between resources/conf and resources/WEB-INF.
The rest stays as I suggested it?
hmm, I don't understand what you mean with put between. The idea is
that the web application goes into COB-INF. Meta data and component
configuration goes into META-INF. There is no need for a
resources/samples, resources/WEB-INF or resources/conf directory.
With 'between' I meant .../resources/COB-INF/samples - sorry for my bad
phrasing.
But looking at cocoon-deployer-plugin-demo it looks more like the
following:
samples - cocoon-block-sample/src/main/resources/COB-INF
WEB-INF/xconf - cocoon-block-impl/src/main/resources/META-INF/xconf(?)
conf - (? contain *.xweb, *.properties and other files)
I'm still uncertain about the last two directories.
Can you give me some more details (or pointers) which files and
directories from the old blocks map to the new ones?
Once I have this information I can adjust the script to respect this
information.
After analyzing the old blocks in more details I found the following
common directories.
It would be great, if you (or someone else involved in developing the
new blocks) can finish the mapping below ...
WEB-INF/sitemap-additions - ? (contains sitemap snippets in *.xconf files)
WEB-INF/xconf - cocoon-block-impl/src/main/resources/META-INF/xconf?
conf - ? (contains *.xweb, *.properties and other files)
java - cocoon-block-impl/src/main/java
samples - cocoon-block-sample/src/main/resources/COB-INF
test - cocoon-block-impl/src/test/java
Thanks,
Andreas
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work
to do, but at least some easy parts can be automated this way.
It handles the following directories from the old blocks:
* java
* test
* conf
* WEB-INF
* samples
Currently the directories are only copied and not moved via 'svn mv'.
I wrapped the commands for moving directories into the function
MoveDir() which can be adjusted to perform svn operations.
The converted directory structure looks like this (blockname
refers to the directory name of the old blocks):
cocoon-blockname
+-cocoon-blockname-impl
| +-src
| | +-main
| | | +-java ('java' from old blocks)
| | | +-resources
| | | | +-WEB-INF ('WEB-INF' from old blocks)
| | | | +-conf ('conf' from old blocks)
| | +-test
| | | +-java ('test' from old blocks)
| +-cocoon-blockname-sample
| +-src
| | +-main
| | | +-resources
| | | | +-samples ('samples' from old blocks)
It would be great if somebody can have a look at it, if I got
everything right.
Next step would be to adjust MoveDir() for svn operations and to
handle pom.xml.
I don't know if the handling of pom.xml can be easily automated,
since it has to be split into 3 pom files.
Andreas, thanks for getting involved! Your work looks good; could
you please make some changes to the directory structure of the new
block? What we need is a structure as used in
cocoon-deployer-plugin-demo:
src
main
java
resources
COB-INF -- the webapp here (e.g. samples)
META-INF -- component configurations here
This is the right structure for real blocks. In order to satisfy
our current needs of deploying into a web application that does
*not* use the blocks-fw, we can extract the JAR into several places
from within an Ant script or a Mojo:
COB-INF-- [web-app]/samples
META-INF -- [web-app]/WEB-INF/xconf
the JAR itself -- [web-app]/WEB-INF/lib
It shouldn't matter that we use the new structure.
Thanks for the hints.
Do I understand it right, if I put COB-INF between resources/samples
and META-INF between resources/conf and resources/WEB-INF.
The rest stays as I suggested it?
hmm, I don't understand what you mean with put between. The idea is
that the web application goes into COB-INF. Meta data and component
configuration goes into META-INF. There is no need for a
resources/samples, resources/WEB-INF or resources/conf directory.
With 'between' I meant .../resources/COB-INF/samples - sorry for my bad
phrasing.
But looking at cocoon-deployer-plugin-demo it looks more like the
following:
samples - cocoon-block-sample/src/main/resources/COB-INF
WEB-INF/xconf - cocoon-block-impl/src/main/resources/META-INF/xconf(?)
conf - (? contain *.xweb, *.properties and other files)
I'm still uncertain about the last two directories.
Can you give me some more details (or pointers) which files and
directories from the old blocks map to the new ones?
Once I have this information I can adjust the script to respect this
information.
Sorry, I was a bit unclear. I agree with you to put all the configuration files
into cocoon-block-impl/src/main/resources/META-INF/conf. These files won't be
needed with the blocks-fw and will simply be ignored. Actually this means that
you can do under META-INF whatever you want ;-)
The deployer will read all files from META-INF/conf and put them at deployment
time into the correct directories. real blocks will be self-contained and it
will not be necessary to spread configuration files.
Are there other file types or directories that you don't know where to put them?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Andreas Hochsteger wrote:
After analyzing the old blocks in more details I found the following
common directories.
It would be great, if you (or someone else involved in developing the
new blocks) can finish the mapping below ...
ok, forget my last response. I'll change it in some points:
WEB-INF/sitemap-additions - ? (contains sitemap snippets in *.xconf files)
cocoon-block-impl/src/main/resources/META-INF/legacy/sitemap-additions
WEB-INF/xconf - cocoon-block-impl/src/main/resources/META-INF/xconf?
cocoon-block-impl/src/main/resources/META-INF/legacy/xconf
conf - ? (contains *.xweb, *.properties and other files)
cocoon-block-impl/src/main/resources/META-INF/legacy/conf
java - cocoon-block-impl/src/main/java
ok
samples - cocoon-block-sample/src/main/resources/COB-INF
ok
test - cocoon-block-impl/src/test/java
ok
The idea is to collect all old configuration files within one directory. I
called it legacy - if somebody has a better name, it would be the right time now
to let us know ;-)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
After analyzing the old blocks in more details I found the following
common directories.
It would be great, if you (or someone else involved in developing the
new blocks) can finish the mapping below ...
ok, forget my last response. I'll change it in some points:
WEB-INF/sitemap-additions - ? (contains sitemap snippets in *.xconf
files)
cocoon-block-impl/src/main/resources/META-INF/legacy/sitemap-additions
WEB-INF/xconf - cocoon-block-impl/src/main/resources/META-INF/xconf?
cocoon-block-impl/src/main/resources/META-INF/legacy/xconf
conf - ? (contains *.xweb, *.properties and other files)
cocoon-block-impl/src/main/resources/META-INF/legacy/conf
java - cocoon-block-impl/src/main/java
ok
samples - cocoon-block-sample/src/main/resources/COB-INF
ok
test - cocoon-block-impl/src/test/java
ok
The idea is to collect all old configuration files within one directory.
I called it legacy - if somebody has a better name, it would be the
right time now to let us know ;-)
Thanks, Reinhard, this really helped me very much!
Attached is a new version which uses the mappings from above.
The SVN-Commands are already added but commented-out and replaced with
copy commands to be easier to test.
One question popped up during testing:
Is it really required to move the directories?
Isn't it better to do a 'svn cp' (which is a cheap copy anyway) and keep
the old blocks at their old location?
This way it would be better to test and experiment since moving may
disrupt both the cocoon-trunk and blocks repository (which is also used
by 2.1 if I'm not mistaken).
It would be great, if somebody could try the script and give me some
more feedback.
Only 2 variables have to be adjusted:
* blksrc: Local directory where
https://svn.apache.org/repos/asf/cocoon/blocks is checked out
* blkdest: Local directory where
https://svn.apache.org/repos/asf/cocoon/trunk is checked out
Usage: ./m10n-blocks.sh blockname...
Example: ./m10n-blocks.sh asciiart faces
The script is written using standard Unix Shell and is tested on WinXP
using Cygwin.
Thanks,
Andreas
#!/bin/sh
# Author: Andreas Hochsteger [EMAIL PROTECTED]
# Description:
# This script partly automates the conversion of the directory structure
# of the old blocks to the mavenized blocks.
# Usage: m10n-blocks.sh blockname...
# Local directory where https://svn.apache.org/repos/asf/cocoon/blocks is
checked out:
blksrc=cocoon-blocks
# Local directory where https://svn.apache.org/repos/asf/cocoon/trunk is
checked out:
blkdest=cocoon-trunk
# List of blocks (old name) to be converted - read from the command line:
blocks=$@
# Argument: from to
function MoveDir() {
if [ -d $1 ]; then
echo Moving $1 to $2 ...
# TODO: This is just for testing:
cp -r $1 $2
# TODO: Replace cp from above with svn command:
#svn mv $1 $2
fi
}
# Argument: blockname
function ConvertBlock() {
block=$1
blockbase=$blkdest/cocoon-$block
# Create initial directory structure:
mkdir -p $blockbase/cocoon-$block-impl/src/main/resources/META-INF/legacy
mkdir -p $blockbase/cocoon-$block-impl/src/test
mkdir -p $blockbase/cocoon-$block-sample/src/main/resources
# TODO: Add initial directory structure to svn:
#svn add $blockbase
# Move Java sources:
MoveDir $blksrc/$block/trunk/java
$blockbase/cocoon-$block-impl/src/main/java
# Move Java test sources:
MoveDir $blksrc/$block/trunk/test
$blockbase/cocoon-$block-impl/src/test/java
# Move xconf resources:
MoveDir $blksrc/$block/trunk/WEB-INF/xconf
$blockbase/cocoon-$block-impl/src/main/resources/META-INF/legacy/xconf
# Move sitemap-additions resources:
MoveDir $blksrc/$block/trunk/WEB-INF/sitemap-additions
$blockbase/cocoon-$block-impl/src/main/resources/META-INF/legacy/sitemap-additions
# Move WEB-INF resources:
MoveDir $blksrc/$block/trunk/conf
$blockbase/cocoon-$block-impl/src/main/resources/META-INF/legacy/conf
# Move sample resources:
MoveDir $blksrc/$block/trunk/samples
$blockbase/cocoon-$block-sample/src/main/resources/COB-INF
}
# Convert the blocks:
for b in $blocks; do
echo Converting block $block ...
ConvertBlock $b
echo
done
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
I successfully built cocoon-linkrewriter using 'mvn package' with the
converted directory structure using the conversion script and 2 new and
one adopted pom file.
I wanted to attach them, but for some reasons my SMTP server rejected
them as SPAM. :-(
I used the following conventions for the block poms:
* version: 1.0-SNAPSHOT
* sample depends only on impl
* impl depends on cocoon-core (and other direct dependencies) - based on
the existing pom of the old block
* parent declares sample and impl as modules
Could somebody please have a look at the attached poms?
I'll try to extend the script to generate the parent and sample poms
automatically and adjust the impl pom (based on the old block pom).
Thanks,
Andreas
Andreas Hochsteger schrieb:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
After analyzing the old blocks in more details I found the following
common directories.
It would be great, if you (or someone else involved in developing the
new blocks) can finish the mapping below ...
ok, forget my last response. I'll change it in some points:
WEB-INF/sitemap-additions - ? (contains sitemap snippets in *.xconf
files)
cocoon-block-impl/src/main/resources/META-INF/legacy/sitemap-additions
WEB-INF/xconf - cocoon-block-impl/src/main/resources/META-INF/xconf?
cocoon-block-impl/src/main/resources/META-INF/legacy/xconf
conf - ? (contains *.xweb, *.properties and other files)
cocoon-block-impl/src/main/resources/META-INF/legacy/conf
java - cocoon-block-impl/src/main/java
ok
samples - cocoon-block-sample/src/main/resources/COB-INF
ok
test - cocoon-block-impl/src/test/java
ok
The idea is to collect all old configuration files within one
directory. I called it legacy - if somebody has a better name, it
would be the right time now to let us know ;-)
Thanks, Reinhard, this really helped me very much!
Attached is a new version which uses the mappings from above.
The SVN-Commands are already added but commented-out and replaced with
copy commands to be easier to test.
One question popped up during testing:
Is it really required to move the directories?
Isn't it better to do a 'svn cp' (which is a cheap copy anyway) and keep
the old blocks at their old location?
This way it would be better to test and experiment since moving may
disrupt both the cocoon-trunk and blocks repository (which is also used
by 2.1 if I'm not mistaken).
It would be great, if somebody could try the script and give me some
more feedback.
Only 2 variables have to be adjusted:
* blksrc: Local directory where
https://svn.apache.org/repos/asf/cocoon/blocks is checked out
* blkdest: Local directory where
https://svn.apache.org/repos/asf/cocoon/trunk is checked out
Usage: ./m10n-blocks.sh blockname...
Example: ./m10n-blocks.sh asciiart faces
The script is written using standard Unix Shell and is tested on WinXP
using Cygwin.
Thanks,
Andreas
#!/bin/sh
# Author: Andreas Hochsteger [EMAIL PROTECTED]
# Description:
# This script partly automates the conversion of the directory structure
# of the old blocks to the mavenized blocks.
# Usage: m10n-blocks.sh blockname...
# Local directory where https://svn.apache.org/repos/asf/cocoon/blocks is
checked out:
blksrc=cocoon-blocks
# Local directory where https://svn.apache.org/repos/asf/cocoon/trunk is
checked out:
blkdest=cocoon-trunk
# List of blocks (old name) to be converted - read from the command line:
blocks=$@
# Argument: from to
function MoveDir() {
if [ -d $1 ]; then
echo Moving $1 to $2 ...
# TODO: This is just for testing:
cp -r $1 $2
# TODO: Replace cp from above with svn command:
#svn mv $1 $2
fi
}
# Argument: blockname
function ConvertBlock() {
block=$1
blockbase=$blkdest/cocoon-$block
# Create initial directory structure:
mkdir -p $blockbase/cocoon-$block-impl/src/main/resources/META-INF/legacy
mkdir -p $blockbase/cocoon-$block-impl/src/test
mkdir -p $blockbase/cocoon-$block-sample/src/main/resources
# TODO: Add initial directory structure to svn:
#svn add $blockbase
# Move Java sources:
MoveDir $blksrc/$block/trunk/java
$blockbase/cocoon-$block-impl/src/main/java
# Move Java test sources:
MoveDir $blksrc/$block/trunk/test
$blockbase/cocoon-$block-impl/src/test/java
# Move xconf resources:
MoveDir $blksrc/$block/trunk/WEB-INF/xconf
$blockbase/cocoon-$block-impl/src/main/resources/META-INF/legacy/xconf
# Move sitemap-additions resources:
MoveDir $blksrc/$block/trunk/WEB-INF/sitemap-additions
$blockbase/cocoon-$block-impl/src/main/resources/META-INF/legacy/sitemap-additions
# Move WEB-INF resources:
MoveDir $blksrc/$block/trunk/conf
$blockbase/cocoon-$block-impl/src/main/resources/META-INF/legacy/conf
# Move sample resources:
MoveDir $blksrc/$block/trunk/samples
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Andreas Hochsteger wrote: I successfully built cocoon-linkrewriter using 'mvn package' with the converted directory structure using the conversion script and 2 new and one adopted pom file. I wanted to attach them, but for some reasons my SMTP server rejected them as SPAM. :-( I used the following conventions for the block poms: * version: 1.0-SNAPSHOT * sample depends only on impl * impl depends on cocoon-core (and other direct dependencies) - based on the existing pom of the old block * parent declares sample and impl as modules Could somebody please have a look at the attached poms? I'll try to extend the script to generate the parent and sample poms automatically and adjust the impl pom (based on the old block pom). Create a jira issue and attach any files relating to this work to that issue. You're doing good work. Regards, Upayavira
Re: [RT] a simple release plan
Reinhard Poetz wrote:
I want to add some thoughts to Daniel's idea of writing some Ant script
for the build: trunk has been mavenized and split up into many modules.
The missing thing is some tool that will create a web application out of
a number of blocks. In a world of real blocks that's the job of the
deployer that I wrote.
I will extend the deployer over the weekend. It probably won't do all the things
that we need, but as the interest in getting it done is high ATM, I hope that
sombody else picks up my work and continues next week.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] a simple release plan
Le 16 mars 06 à 08:44, Carsten Ziegeler a écrit : ...Getting a 2.3 out with the proposed plan is doable in the short term imho... Would it be possible to prove this without touching the current trunk, so as not to disturb the work of those working on the blocks and OSGI stuff? By creating a branch for 2.3 or something? Or even tagging 2.1.9 and continue work in that branch towards 2.3? If yes, work on the trunk can continue at the appropriate pace for those who are working on it, and others can play with the proposed 2.3 and vote in due time, about whether to release a 2.3 milestone or wait for the trunk. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] a simple release plan
Upayavira wrote:
Carsten has offered a suggestion that _he_ is prepared to implement. I
would like to hear other proposals from people of things that _they_ are
prepared to implement. Only that way will we move beyond this impass.
There are many documents that explain the roadmap Daniel and I follow ATM. The
only thing we are asking for is that we all work on trunk. Everything else is
another internal fork (didn't we agree that this was a bad idea?) and we have to
make sure again that everything gets synced again and again. That's the reason
for the -1 on Carsten's proposal of Daniel and me.
So what's the overhead for people that want to work on trunk? They should make
sure that the testcases run through and they should run the samples before they
commit. Is this such a special requirement? Does somebody have to understand in
detail what the testcases cover?
If a testcase gets broken *locally* by a developer, the developer should discuss
the change on [EMAIL PROTECTED] and then people can decide together how to proceed.
That should be the standard procedure in every development project, may it be
opensource or commercial.
Can we agree on these very basic rules?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [RT] a simple release plan
Reinhard Poetz wrote: Upayavira wrote: Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond this impass. There are many documents that explain the roadmap Daniel and I follow ATM. The only thing we are asking for is that we all work on trunk. Everything else is another internal fork (didn't we agree that this was a bad idea?) and we have to make sure again that everything gets synced again and again. That's the reason for the -1 on Carsten's proposal of Daniel and me. So what's the overhead for people that want to work on trunk? They should make sure that the testcases run through and they should run the samples before they commit. Is this such a special requirement? Does somebody have to understand in detail what the testcases cover? If a testcase gets broken *locally* by a developer, the developer should discuss the change on [EMAIL PROTECTED] and then people can decide together how to proceed. That should be the standard procedure in every development project, may it be opensource or commercial. Can we agree on these very basic rules? The overhead for people to work on trunk is that trunk is largely unknown. It is my perception that many people have little confidence that trunk actually works. Fear that it will change frequently, and that they will have to invest a lot of effort (time which they don't have) in order to keep up. That's the concern I'm trying to address. Not whether trunk _actually_ works, but how people in our community _feel_ about it. It may be just 'emotion', but it really is important, as, IMO, emotion (or could I say emotional investment) is the fundamental underpinning of our community. If that fades away, away with it goes our community. I'm looking for ideas of ways and suggestions as to how our community can move on with this more 'fuzzy' stuff - and get more of us developing and innovating again. Upayavira
Re: [RT] a simple release plan
On 3/16/06, Upayavira [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: Upayavira wrote: Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond this impass. There are many documents that explain the roadmap Daniel and I follow ATM. The only thing we are asking for is that we all work on trunk. Everything else is another internal fork (didn't we agree that this was a bad idea?) and we have to make sure again that everything gets synced again and again. That's the reason for the -1 on Carsten's proposal of Daniel and me. So what's the overhead for people that want to work on trunk? They should make sure that the testcases run through and they should run the samples before they commit. Is this such a special requirement? Does somebody have to understand in detail what the testcases cover? If a testcase gets broken *locally* by a developer, the developer should discuss the change on [EMAIL PROTECTED] and then people can decide together how to proceed. That should be the standard procedure in every development project, may it be opensource or commercial. Can we agree on these very basic rules? The overhead for people to work on trunk is that trunk is largely unknown. It is my perception that many people have little confidence that trunk actually works. Fear that it will change frequently, and that they will have to invest a lot of effort (time which they don't have) in order to keep up. That's the concern I'm trying to address. Not whether trunk _actually_ works, but how people in our community _feel_ about it. It may be just Some comments from the peanut gallery... I used to keep a trunk updated and build periodically. My ability to do that went away with Mavenization. I was willing to climb a Maven learning curve, but I lost confidence when I tried to build, say 4 times, and it succeeds one time out of 4 for some unknown reason even though I didn't change anything in between builds - simply built one after another. If one can't reliably/consistently build without having to worry about lunar alignment, then they won't have confidence. This has been a long way of saying that my loss of confidence in Cocoon's trunk relates to Maven not blocks. Fix maven so that it consistently builds and you'll be a long way towards restoring trust in trunk I think. I'll just add that this previous paragraph is about my perception, not necessarily trunk's reality. In other words, it may be that I'm doing something wrong, but I've followed the various threads and instructions faithfully. --tim 'emotion', but it really is important, as, IMO, emotion (or could I say emotional investment) is the fundamental underpinning of our community. If that fades away, away with it goes our community. I'm looking for ideas of ways and suggestions as to how our community can move on with this more 'fuzzy' stuff - and get more of us developing and innovating again. Upayavira
Re: [RT] a simple release plan
Reinhard Poetz schrieb: Upayavira wrote: Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond this impass. There are many documents that explain the roadmap Daniel and I follow ATM. The only thing we are asking for is that we all work on trunk. Everything else is another internal fork (didn't we agree that this was a bad idea?) and we have to make sure again that everything gets synced again and again. That's the reason for the -1 on Carsten's proposal of Daniel and me. Hmm, yes, but work on trunk might mean breaking blocks - as my changes did recently. So it's not that easy. In addition I'm wondering what will happen with all the work already done on trunk with real blocks? What about the includes in configuration etc. It more and more seems that this work is useless for real blocks and is just a waste of time if it gets never released. So what's the overhead for people that want to work on trunk? They should make sure that the testcases run through and they should run the samples before they commit. Is this such a special requirement? Does somebody have to understand in detail what the testcases cover? Trunk is not working out of the box; testing the samples is really a pain; for example I can't test the new portal version as this would require porting all missing blocks to the new structure, getting them compiled and more important its a rather huge effort to build the resulting webapp. And imho this is a real problem; noone will look at turnk as long as it is this way; we scare people away; not to mention that people start thinking that moving to maven was the wrong move (I personally still think that maven is the right way). If a testcase gets broken *locally* by a developer, the developer should discuss the change on [EMAIL PROTECTED] and then people can decide together how to proceed. That should be the standard procedure in every development project, may it be opensource or commercial. Can we agree on these very basic rules? Some of our test cases are already broken for a long time; so it's hard to tell if for example my new changes broke something or if the test was already broken; currently I think our tests are not really used. But of course I agree with such a rule in general. If it would come to a vote, I would personally favour a split. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] a simple release plan
Hi, Tim Williams wrote: On 3/16/06, Upayavira [EMAIL PROTECTED] wrote: The overhead for people to work on trunk is that trunk is largely unknown. It is my perception that many people have little confidence that trunk actually works. Fear that it will change frequently, and that they will have to invest a lot of effort (time which they don't have) in order to keep up. Upayavira, trunk will always change frequently (it's development HEAD after all). I think the real problem is that no-one has a 30 second overview of 2.2. Something like It's still the same Cocoon, it's not much different for users, it's just easier to build and more extensible. Some anti-FUD, if you like ;-) There's also the problem Tim refers to: I was willing to climb a Maven learning curve, but I lost confidence when I tried to build, say 4 times, and it succeeds one time out of 4 for some unknown reason even though I didn't change anything in between builds - simply built one after another. I've dealt with the maven curve on several other projects, but imho there's a _serious_ problem with m2 and the constant network timeouts when trying to build Cocoon. Until there's a workable solution for this, I think there'll be a continued perception that 2.2 is broken, even though the code itself is fine. As for the 2.3 idea, since I'm commenting anyway ... I think the overhead of syncing will mean that 2.2 and 2.1 will suffer. Whether the suffering is worse than the problems with 2.2, I wouldn't like to say. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [RT] a simple release plan
* Reinhard Poetz: If somebody has the need of writing some deployment tool without having to understand blocks-fw, he could write an Ant script or an M2 Mojo that get some kind of configuration which blocks should be installed: configuration blocks blockorg.apache.cocoon:forms-impl:1.0-SNAPSHOT/block blockorg.apache.cocoon:template-impl:1.0-SNAPSHOT/block ... /blocks /configuration Then the mojo deploys them to the right place and takes the component configuration out of it and puts it into /WEB-INF/xconf. As M2 offers some Ant tasks to get access to M2 repos, this could be done with Ant too. That's exactly what we need now. A tool that installs all blocks into the webapp. I'm +1 for making a new release if it includes the Maven build, we just have to write this tool. We have to focus exactly on this simple task to be able to make a clean release. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [RT] a simple release plan
On 3/16/06, Upayavira [EMAIL PROTECTED] wrote: snip/ Thus, we have 'one way' of doing it, that people don't want to follow, for their own reasons, and because of this, nothing at all happens, and our community gets weaker by the day. Oh, come on. There's no real evidence for this being true. If it is happening it is only because people start to spread FUD instead of putting some energy into actually trying to work with trunk We need to have the scope for differences, alternative approaches, conflicts, etc, and then switch to the best when a best clearly shows itself. What we have now is one unimplemented ideal that we are supposedly working towards (I'm talking of the community here, not you yourself). And that ideal is for some psychological reason preventing others from engaging with their own ideas. It is that psychological block that I want to find ways to remove. Really, what the technology is that helps to remove that block, I do not care. I just want to see that block removed so that the creativity of the many can flow again. Once more I ask: what is that you want to do that you can't currently do? Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond this impass. Daniel and Bertrand have already given you a reasonable proposal. Carsten's proposal sounds reasonable on the surface, but the fact is, that it will actually take a lot of focus away from the current trunk. For years people have been saying they need real blocks, now all of a sudden, there is a need to split a new fork so that a Spring based container can get released? I don't get it: sure it will help some people, so will real blocks. It seems to me that if the same energy was spent getting the current trunk cleaned up that would go into a 2.3 release this discussion) then the job would be done. Here's an analogy for you: a man gets engaged to a woman he has loved for many years. A week before the wedding his buddies take him out for a bachelor party and he falls in lust with a young dancer who flirts with him (and happens to take a lot of money from his buddies without him really noticing). Should he break off his engagement with his fiance to start chasing the young dancer? -- Peter Hunsberger
Re: [RT] a simple release plan
Carsten Ziegeler wrote: Trunk is not working out of the box; testing the samples is really a pain; for example I can't test the new portal version as this would require porting all missing blocks to the new structure, getting them compiled and more important its a rather huge effort to build the resulting webapp. And imho this is a real problem; noone will look at turnk as long as it is this way; we scare people away; not to mention that people start thinking that moving to maven was the wrong move (I personally still think that maven is the right way). This is exactly my problem. I have stopped applying patches to trunk that I am applying to the 2.1 branch because I cannot test them because I cannot get a full working Cocoon. I'm not interested in getting all the blocks stuff or maven stuff or whatever to work just to be able to apply patches. If a testcase gets broken *locally* by a developer, the developer should discuss the change on [EMAIL PROTECTED] and then people can decide together how to proceed. That should be the standard procedure in every development project, may it be opensource or commercial. Can we agree on these very basic rules? Some of our test cases are already broken for a long time; so it's hard to tell if for example my new changes broke something or if the test was already broken; currently I think our tests are not really used. But of course I agree with such a rule in general. If it would come to a vote, I would personally favour a split. I love test cases. Frankly, I didn't really know we had any with the ant build. I like that the maven build runs them and shows that they fail. I hate that no one wants to fix them in trunk. Carsten
Re: [RT] a simple release plan
Peter Hunsberger wrote: On 3/16/06, Upayavira [EMAIL PROTECTED] wrote: snip/ Thus, we have 'one way' of doing it, that people don't want to follow, for their own reasons, and because of this, nothing at all happens, and our community gets weaker by the day. Oh, come on. There's no real evidence for this being true. This is my opinion, based upon personal conversations over time, and observations I have heard others make. If it is happening it is only because people start to spread FUD instead of putting some energy into actually trying to work with trunk You can view what I say as FUD if you like, although I clearly don't see it that way. The problem for me is that I don't have the time to invest in dealing with the sorts of issues that people have already mentioned in relation to working with trunk. Yes, it can work, if you give it the effort. But in order to scratch _my_ itch, I currently need to invest in core infrastructure stuff to get trunk working at all, and it may well be the sort of thing that I personally am not suited to doing. We need to have the scope for differences, alternative approaches, conflicts, etc, and then switch to the best when a best clearly shows itself. What we have now is one unimplemented ideal that we are supposedly working towards (I'm talking of the community here, not you yourself). And that ideal is for some psychological reason preventing others from engaging with their own ideas. It is that psychological block that I want to find ways to remove. Really, what the technology is that helps to remove that block, I do not care. I just want to see that block removed so that the creativity of the many can flow again. Once more I ask: what is that you want to do that you can't currently do? I want to see active development of trunk by more than a limited few. Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond this impass. Daniel and Bertrand have already given you a reasonable proposal. Yes, I liked Bertrand's idea. Not sure which one of Daniel's you were referring to. What I'm trying to do is encourage people to brin forward proposals that _they_ are prepared to implement, not ones that _others_ might implement. Carsten's proposal sounds reasonable on the surface, but the fact is, that it will actually take a lot of focus away from the current trunk. For years people have been saying they need real blocks, now all of a sudden, there is a need to split a new fork so that a Spring based container can get released? I don't get it: sure it will help some people, so will real blocks. It seems to me that if the same energy was spent getting the current trunk cleaned up that would go into a 2.3 release this discussion) then the job would be done. For years some people have been saying they need real blocks, and others have been wondering what all of the fuss is about. Here's an analogy for you: a man gets engaged to a woman he has loved for many years. A week before the wedding his buddies take him out for a bachelor party and he falls in lust with a young dancer who flirts with him (and happens to take a lot of money from his buddies without him really noticing). Should he break off his engagement with his fiance to start chasing the young dancer? That isn't at all what I am proposing. I want to see 'ordinary' cocoon development happening in parallel with real blocks, rather than ordinary development stalled while waiting for real blocks. Regards, Upayavira
Re: [RT] a simple release plan
Peter Hunsberger wrote: On 3/16/06, Upayavira [EMAIL PROTECTED] wrote: snip/ Thus, we have 'one way' of doing it, that people don't want to follow, for their own reasons, and because of this, nothing at all happens, and our community gets weaker by the day. Oh, come on. There's no real evidence for this being true. If it is happening it is only because people start to spread FUD instead of putting some energy into actually trying to work with trunk I think this thread is the evidence. I've lost confidence that anything beyond 2.1.x will ever get delivered. I hear lots of promises but they don't seem to get fulfilled. We need to have the scope for differences, alternative approaches, conflicts, etc, and then switch to the best when a best clearly shows itself. What we have now is one unimplemented ideal that we are supposedly working towards (I'm talking of the community here, not you yourself). And that ideal is for some psychological reason preventing others from engaging with their own ideas. It is that psychological block that I want to find ways to remove. Really, what the technology is that helps to remove that block, I do not care. I just want to see that block removed so that the creativity of the many can flow again. Once more I ask: what is that you want to do that you can't currently do? Run a full Cocoon in trunk (i.e. get a sample site up that looks and behaves pretty much the same as the 2.1 branch. Not just 2 or 3 blocks I don't use. Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond this impass. Daniel and Bertrand have already given you a reasonable proposal. Carsten's proposal sounds reasonable on the surface, but the fact is, that it will actually take a lot of focus away from the current trunk. For years people have been saying they need real blocks, now all of a sudden, there is a need to split a new fork so that a Spring based container can get released? I don't get it: sure it will help some people, so will real blocks. It seems to me that if the same energy was spent getting the current trunk cleaned up that would go into a 2.3 release this discussion) then the job would be done. While real blocks seem appealing there is no evidence yet that they will work well; logistically, performance wise, etc. So putting all our eggs in that basket is risky. And frankly, full Mavenization would provide me with 90% of what I want in the way of a build process. Unfortunately, from what I can tell that work is nowhere near complete. But besides this, trunk contains a large number of new features, from allowing non-poolable Transformers, Generators, etc., to a new portal internal architecture, to a Spring core, external configuration parameters and more. All Carsten is proposing is a way to get those features out the door in the next few months. Now, if the proper way to do that is to create a 2.3 branch and leave trunk alone I'd be fine with that, except that I still am not going to touch trunk until I can build and run it all. Your suggestion that the time and energy be focused on trunk instead isn't realistic or true. Very few people understand how to make that happen or seem to want to participate in that. Remember, this is a do-ocracy. The fact that it hasn't happened should give you an idea of how well that idea will work. Here's an analogy for you: a man gets engaged to a woman he has loved for many years. A week before the wedding his buddies take him out for a bachelor party and he falls in lust with a young dancer who flirts with him (and happens to take a lot of money from his buddies without him really noticing). Should he break off his engagement with his fiance to start chasing the young dancer? Nice analogy. It has nothing to do with the current situation. -- Peter Hunsberger
Re: [RT] a simple release plan
Daniel Fagerstrom wrote: The blocks FUD == I'd like to remind once again that the blocks work doesn't destabilize the traditional use of Cocoon the slightest, see http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2. It just cannot affect that as there are no dependencies from the traditional parts to the blocks fw whatsoever. Concerning the OSGi stuff it is not even part of the build yet. So the idea that the block work should hinder anyone to work as usual is just plain wrong. M10N What hinder people to work as usual is that the M10N isn't finished. Now it isn't that hard to use Cocoon anyway as I described in the reference above. But of course it would be nicer to be able to use Cocoon with some blocks OOTB. If you don't want to take part in working on the blocks fw and deployer and is impatient, it wouldn't be that hard to write a plugin or an Ant task called from Maven that does the file copying that is described in the reference above. BTW, I'm quite surprised that you want to go back to the messy Ant build from 2.1.x after having argued for building Cocoon with Maven for years. Have you lost your faith in Maven? Same feeling here. I honestly admit being rather clueless both in OSGification and M10N (not enough time to invest to climb the learning curve). Now they obviously seem to be steps forward. Daniel says that classical Cocoon code doesn't depend on the infrastructure that's being built for real blocks and OSGi. And we seem pretty close to a full M10N. AFAIU, what's needed to finish it is mainly the equivalent of build webapp. If the above assumptions are true, splitting the code base and going back to the Ant build seems a huge step backwards, and would relegate OSGi and M10N to scratchpad status. That would be bad and would mean that this community is no longer able to innovate (provocative side note: are we really innovating? [1]). Sylvain [1] http://www.eclipsezone.com/eclipse/forums/t64085.rhtml -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [RT] a simple release plan
* Sylvain Wallez: Daniel says that classical Cocoon code doesn't depend on the infrastructure that's being built for real blocks and OSGi. And we seem pretty close to a full M10N. AFAIU, what's needed to finish it is mainly the equivalent of build webapp. Exactly! If the above assumptions are true, splitting the code base and going back to the Ant build seems a huge step backwards, and would relegate OSGi and M10N to scratchpad status. Keeping M10N and providing a « build webapp » script is definitely the way to go. -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [RT] a simple release plan
Jean-Baptiste Quenot wrote: * Sylvain Wallez: Daniel says that classical Cocoon code doesn't depend on the infrastructure that's being built for real blocks and OSGi. And we seem pretty close to a full M10N. AFAIU, what's needed to finish it is mainly the equivalent of build webapp. Exactly! If the above assumptions are true, splitting the code base and going back to the Ant build seems a huge step backwards, and would relegate OSGi and M10N to scratchpad status. Keeping M10N and providing a « build webapp » script is definitely the way to go. Is that a volunteer? ;-) Regards, Upayavira
Re: [RT] a simple release plan
Sylvain Wallez wrote: Daniel Fagerstrom wrote: BTW, I'm quite surprised that you want to go back to the messy Ant build from 2.1.x after having argued for building Cocoon with Maven for years. Have you lost your faith in Maven? Same feeling here. I honestly admit being rather clueless both in OSGification and M10N (not enough time to invest to climb the learning curve). Now they obviously seem to be steps forward. Daniel says that classical Cocoon code doesn't depend on the infrastructure that's being built for real blocks and OSGi. And we seem pretty close to a full M10N. AFAIU, what's needed to finish it is mainly the equivalent of build webapp If that is the case then I'd agree as I would prefer to use a maven based build. However: 1. I'm pretty sure all the blocks have not been mavenized. (I could be wrong, but I don't seem to be able to check out trunk as there is an external that uses http which won't go through my employer's firewall). 2. The maven build seems to have serious problems with some of the repositories (I believe primarily those at apache). If the above assumptions are true, splitting the code base and going back to the Ant build seems a huge step backwards, and would relegate OSGi and M10N to scratchpad status. That would be bad and would mean that this community is no longer able to innovate (provocative side note: are we really innovating? [1]). Innovation is great. However, if it is never released it is completely wasted. We keep saying release often but then keep putting up roadblocks to make that impossible. Ralph
Re: [RT] a simple release plan
Hi, Ralph Goers wrote: 1. I'm pretty sure all the blocks have not been mavenized. Is there a list of blocks to mavenise anywhere, with instructions of how to do it? I don't mind helping with this. (I could be wrong, but I don't seem to be able to check out trunk as there is an external that uses http which won't go through my employer's firewall). Do you mean https? If so that probably needs fixing ... If you do mean http is blocked, there's probably not much we can do about that ;-) 2. The maven build seems to have serious problems with some of the repositories (I believe primarily those at apache). Is there any way we can set up a Cocoon mirror for the time being, until the repository problems are resolved? I'm sure several of us here can set up a repo, and it could be the default used by Cocoon. (I assume the Maven folk know about the repo troubles and are working on it?) Innovation is great. However, if it is never released it is completely wasted. We keep saying release often but then keep putting up roadblocks to make that impossible. Just out of interest, how many others have actually downloaded and _tried_ the new mavenised 2.2? I know I only updated and tried it last weekend, after the thread with instructions on how to do so. Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [RT] a simple release plan
Andrew Savory wrote: Hi, Ralph Goers wrote: 1. I'm pretty sure all the blocks have not been mavenized. Is there a list of blocks to mavenise anywhere, with instructions of how to do it? I don't mind helping with this. The easy way to tell I suppose is to check out trunk. There are a bunch of cocoon-whatever directories. Compare that list with what is in src/blocks in 2.1. I believe the instructions are in README.m10n.txt. (I could be wrong, but I don't seem to be able to check out trunk as there is an external that uses http which won't go through my employer's firewall). Do you mean https? If so that probably needs fixing ... If you do mean http is blocked, there's probably not much we can do about that ;-) Yes, my employer's firewall is set up so that only https works with svn. That's fine because you need that in order to check in. In any case, I did a clean check out and didn't have the problem. It only happened when I tried to update my existing sandbox. 2. The maven build seems to have serious problems with some of the repositories (I believe primarily those at apache). Is there any way we can set up a Cocoon mirror for the time being, until the repository problems are resolved? I'm sure several of us here can set up a repo, and it could be the default used by Cocoon. (I assume the Maven folk know about the repo troubles and are working on it?) I have no idea. Innovation is great. However, if it is never released it is completely wasted. We keep saying release often but then keep putting up roadblocks to make that impossible. Just out of interest, how many others have actually downloaded and _tried_ the new mavenised 2.2? I know I only updated and tried it last weekend, after the thread with instructions on how to do so. I first tried it at ApacheCon in early December. As I recall it was in a whiteboard at the time. I've tried it several times since then. I've never been able to get a Cocoon up where I could test the code I wanted to modify. I haven't tried it since the email you refer to but I will this weekend. Ralph
Re: [RT] a simple release plan
Hi, Ralph Goers wrote: I first tried it at ApacheCon in early December. As I recall it was in a whiteboard at the time. I've tried it several times since then. I've never been able to get a Cocoon up where I could test the code I wanted to modify. I haven't tried it since the email you refer to but I will this weekend. I followed the instructions David kindly wrote up at: http://cocoon.zones.apache.org/daisy/documentation/g1/798.html (be warned the maven repo network errors mean you have to try several times) ... but haven't yet tried: http://cocoon.zones.apache.org/daisy/documentation/863/g1/796.html Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [RT] a simple release plan
Carsten Ziegeler skrev: Daniel Fagerstrom wrote: SNIP/ Not surprisingly I'm -1 on your points 2 and 3. If you want to continue in that direction which IMO represents a huge step back. I insist on that you prove that it work and that you actually have the persistence to carry it through, on a copy of the trunk in the whiteboard. After that you need to cast a vote about making that the new trunk. Also it should be much easier to update the Ant scripts than changing the directory structure. Anyway, why you would like to make such a huge effort in such an backward pointing direction, instead of helping to finish the blocks work or at least the M10N, is just beyond my imagination. Daniel, as I already said, I appreciate your efforts and blocks are the way to go, no doubt. I can only speak for myself, but I see two advantages of the plan for me (and hopefully for others as well): smaller changes and getting new features today. Changing back to the old directory structure, throwing the Maven build away, and try to get the messy Ant build to work, doesn't seem like such a small change to me. IMO, making Maven insert some configuration file and samples into cocoon-webapp, should be a much smaller task. And what is much more important, it will not split our efforts further or disrupt the current development. Furthermore the switch from ECM++ to Spring you performed, without even bother to cast a vote, was a really large and disruptive change. The Spring/Avalon core is immature and unstable. Right now calls to subsitemaps results in NPE:s. Before we got it in at least in a testable shape I'm against doing any large restructuring of the trunk. I rewrote the core for 2.2 nearly two years ago and it never went into a release! The same with ECM++, the configuration includes, the property configurations etc. Now, we dropped ECM++ in favour of the Spring based container which provides the same functionality plus Spring. And it makes totally sense to me to release this as a new version. Sure, as soon as it is usable again. There is not much work required for this: if we replace the maven build with the ant one, we should have a fully working 2.2 with all the new features. So we only have to move/copy some directories and files and that's it. Moving directories is very destructive to do, your suggestion means that it would be very hard to synchronize blocks in the release and a block-branch. And furthermore I still fail to see why it should be easier to move around directories than to change some paths in the Ant build. Speaking for myself again, I can do this stuff as I know how to move/copy directories and I now how the 2.2 core works and I'm pretty confident that it's working pretty well. Based on what kind of testing do you say that? For me it doesn't work. But I have no clue about blocks or how to finish the maven build. You keep saying that you don't understand the blocks. It is not that much code at all, and we have written tons of descriptions, and giving talks and tutorials on various levels about it during the years. You have met me and Reinhard and earlier Stefano IRL plenty of times. I haven't heard any specific questions about them from you about it. So are you really interested in trying to understand them? Remember, I suggested a solution two weeks ago to get a maven build running, but was told that this is the wrong way and we should wait for blocks. I remember that I told you to go ahead. And that Reinhard asked you to wait because he was close to have a working version of the deployer. Which he actually had within a week as he said. Unfortunately all the blocks stuff stopped working after that you changed the core without running the test cases for the blocks. And I don't have time to invest into blocks or maven right now. That's the simple reason for not being able to help. In addition, the current new core with Spring solves all my day-to-day problems I have with Cocoon. So why not getting this out? The core is not your private playground, it is something that the community owns together. Work in the core require respect for other peoples work. And I can't work any further on the core as this always breaks the blocks stuff, as you kindly pointed out. I didn't point it out in a kindly way. I was, once again, deeply frustrated that you break core contracts and the tests for the stuff that I am developing. If you just did it a few times I would understand it, but it have happens so many times during the years. And I have spend so much frustrating work in trying to get things working again. I don't think that it is to ask for to much that you should check that the same test cases runs both before and after subtle core changes. Now, for the latest case with the container switch, I asked you to work in a branch until the core was stable again. You didn't care about that and you disrupted mine and Reinhard's work, and
Re: [RT] a simple release plan
We are really innovating, as the cited article just contains some parts of the blocks idea. But the rest of the world is definitely catching up. If we focus on self doubt instead of development, we will be overrunned in this area as well. On the more positive side it is an advantage that the ideas are starting to get more attention, it will mean that we can share components and infrastructure with other communities. And that our timing might be right. /Daniel Sylvain Wallez skrev: ... That would be bad and would mean that this community is no longer able to innovate (provocative side note: are we really innovating? [1]). Sylvain [1] http://www.eclipsezone.com/eclipse/forums/t64085.rhtml
Re: [RT] a simple release plan
Ralph Goers skrev: Andrew Savory wrote: Hi, Ralph Goers wrote: 1. I'm pretty sure all the blocks have not been mavenized. Is there a list of blocks to mavenise anywhere, with instructions of how to do it? I don't mind helping with this. The easy way to tell I suppose is to check out trunk. There are a bunch of cocoon-whatever directories. Compare that list with what is in src/blocks in 2.1. I believe the instructions are in README.m10n.txt. Actually all the trunk blocks http://svn.apache.org/repos/asf/cocoon/blocks/ was Mavenized once. Then two things happened: 1) We decided to change to change directory structure to something that followed the Maven standard, and that had some other advantages: http://cocoon.zones.apache.org/daisy/documentation/g1/756.html. All blocks with the new structure are moved to the trunk. 2) We changed group id from apache-cocoon to org.apache.cocoon (in trunk). As the later is the recomended structure for M2. Most of the blocks in http://svn.apache.org/repos/asf/cocoon/blocks/ would probably build again just by fixing the group id. It would of course be nice to switch all to the new directory structure, but that can be done one block at the time when someone feel the itch. --- o0o --- It would also be very valuable if someone with Cocoon zones competence could get the snapshot build running again (http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/). With the snapshots working one just need to check out the blocks that one actually want to develop. (I could be wrong, but I don't seem to be able to check out trunk as there is an external that uses http which won't go through my employer's firewall). Do you mean https? If so that probably needs fixing ... If you do mean http is blocked, there's probably not much we can do about that ;-) Yes, my employer's firewall is set up so that only https works with svn. That's fine because you need that in order to check in. In any case, I did a clean check out and didn't have the problem. It only happened when I tried to update my existing sandbox. 2. The maven build seems to have serious problems with some of the repositories (I believe primarily those at apache). Is there any way we can set up a Cocoon mirror for the time being, until the repository problems are resolved? I'm sure several of us here can set up a repo, and it could be the default used by Cocoon. (I assume the Maven folk know about the repo troubles and are working on it?) IIUC, the main problem is the use lots of libraries that isn't part of the central Maven repository (which is supposed to be mirrored and able to take a lot of load). Jorg is working on getting a release of the Mavenized Excalibur. It is also possible to submit POM:s for upload at Ibiblio http://maven.apache.org/reference/repository-upload.html. /Daniel
Re: [RT] a simple release plan
Reinhard Poetz wrote: Daniel Fagerstrom wrote: The blocks FUD == I'd like to remind once again that the blocks work doesn't destabilize the traditional use of Cocoon the slightest, see http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2. It just cannot affect that as there are no dependencies from the traditional parts to the blocks fw whatsoever. Concerning the OSGi stuff it is not even part of the build yet. So the idea that the block work should hinder anyone to work as usual is just plain wrong. M10N What hinder people to work as usual is that the M10N isn't finished. Now it isn't that hard to use Cocoon anyway as I described in the reference above. But of course it would be nicer to be able to use Cocoon with some blocks OOTB. If you don't want to take part in working on the blocks fw and deployer and is impatient, it wouldn't be that hard to write a plugin or an Ant task called from Maven that does the file copying that is described in the reference above. BTW, I'm quite surprised that you want to go back to the messy Ant build from 2.1.x after having argued for building Cocoon with Maven for years. Have you lost your faith in Maven? Springification === Talking about destabilizing, a couple of weeks ago the trunk was usable after the file copying referred to above. Actually it was so stable that I developed a small customer application with it without any problems. And AFAIU Reinhard have developed a large application in it. This is not the possible anymore, after the Springification. I tried to start a freshly checked out trunk together with the ajax, form and template block after having copied the configuration files and samples to cocoon-webapp as described above. The start page worked, but all access to sub sitemaps gave null pointer exceptions, where the TreeBuilder configuration can't be loaded. IIRC there where other things that was reported that didn't work a couple of weeks ago as well. I suggest that the container should be reasonably stable before even thinking about doing any big moves. --- o0o --- Not surprisingly I'm -1 on your points 2 and 3. If you want to continue in that direction which IMO represents a huge step back. I insist on that you prove that it work and that you actually have the persistence to carry it through, on a copy of the trunk in the whiteboard. After that you need to cast a vote about making that the new trunk. Also it should be much easier to update the Ant scripts than changing the directory structure. Anyway, why you would like to make such a huge effort in such an backward pointing direction, instead of helping to finish the blocks work or at least the M10N, is just beyond my imagination. /Daniel I agree with Daniel. +1 Best Regards, Antonio Gallardo.
[RT] a simple release plan
Ok, here is a simple plan to continue. Please note, that the current trunk has several new things: a new core which can be seen as a follow-up to 2.1.x, the blocks stuff and the maven build. We can use trunk as a direct follow-up to 2.1.x without blocks! As Bertrand suggested we should start with a fresh version number: 2.3. So the plan looks like this: 1. Release 2.1.9 by the end of march as discussed recently This includes freezing 2.1.x and really just doing important bug fixes there. 2. Copy trunk to a new place to continue the blocks development 3. Remove blocks stuff from trunk and use it as a base for 2.3 This includes: using the directory layout from 2.1.x and using the ant build sytem from 2.1.x 4. Sync 2.1.9 and 2.3: there are only a few things which still need to be synced. 5. Release 2.3m1 At the same time the blocks stuff can continue and we are not blocking any development. WDYT? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] a simple release plan
Carsten Ziegeler said the following on 15-03-2006 17:00: At the same time the blocks stuff can continue and we are not blocking any development. WDYT? +1 Bye, Helma
Re: [RT] a simple release plan
Il giorno 15/mar/06, alle ore 17:00, Carsten Ziegeler ha scritto: Ok, here is a simple plan to continue. snip/ WDYT? I like it. I share Upayavira's and others' frustration at not understanding (our fault entirely) what is going on in trunk and being able to help. Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: [RT] a simple release plan
Carsten Ziegeler wrote: Ok, here is a simple plan to continue. Please note, that the current trunk has several new things: a new core which can be seen as a follow-up to 2.1.x, the blocks stuff and the maven build. We can use trunk as a direct follow-up to 2.1.x without blocks! As Bertrand suggested we should start with a fresh version number: 2.3. So the plan looks like this: 1. Release 2.1.9 by the end of march as discussed recently This includes freezing 2.1.x and really just doing important bug fixes there. 2. Copy trunk to a new place to continue the blocks development 3. Remove blocks stuff from trunk and use it as a base for 2.3 This includes: using the directory layout from 2.1.x and using the ant build sytem from 2.1.x 4. Sync 2.1.9 and 2.3: there are only a few things which still need to be synced. 5. Release 2.3m1 At the same time the blocks stuff can continue and we are not blocking any development. WDYT? Carsten +1. Having the maven2 build is important, but there is enough new stuff in trunk that this should ease the pain. Ralph
Re: [RT] a simple release plan
Le 15 mars 06 à 17:00, Carsten Ziegeler a écrit : ...At the same time the blocks stuff can continue and we are not blocking any development... +1 on your plan! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] a simple release plan
The blocks FUD == I'd like to remind once again that the blocks work doesn't destabilize the traditional use of Cocoon the slightest, see http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2. It just cannot affect that as there are no dependencies from the traditional parts to the blocks fw whatsoever. Concerning the OSGi stuff it is not even part of the build yet. So the idea that the block work should hinder anyone to work as usual is just plain wrong. M10N What hinder people to work as usual is that the M10N isn't finished. Now it isn't that hard to use Cocoon anyway as I described in the reference above. But of course it would be nicer to be able to use Cocoon with some blocks OOTB. If you don't want to take part in working on the blocks fw and deployer and is impatient, it wouldn't be that hard to write a plugin or an Ant task called from Maven that does the file copying that is described in the reference above. BTW, I'm quite surprised that you want to go back to the messy Ant build from 2.1.x after having argued for building Cocoon with Maven for years. Have you lost your faith in Maven? Springification === Talking about destabilizing, a couple of weeks ago the trunk was usable after the file copying referred to above. Actually it was so stable that I developed a small customer application with it without any problems. And AFAIU Reinhard have developed a large application in it. This is not the possible anymore, after the Springification. I tried to start a freshly checked out trunk together with the ajax, form and template block after having copied the configuration files and samples to cocoon-webapp as described above. The start page worked, but all access to sub sitemaps gave null pointer exceptions, where the TreeBuilder configuration can't be loaded. IIRC there where other things that was reported that didn't work a couple of weeks ago as well. I suggest that the container should be reasonably stable before even thinking about doing any big moves. --- o0o --- Not surprisingly I'm -1 on your points 2 and 3. If you want to continue in that direction which IMO represents a huge step back. I insist on that you prove that it work and that you actually have the persistence to carry it through, on a copy of the trunk in the whiteboard. After that you need to cast a vote about making that the new trunk. Also it should be much easier to update the Ant scripts than changing the directory structure. Anyway, why you would like to make such a huge effort in such an backward pointing direction, instead of helping to finish the blocks work or at least the M10N, is just beyond my imagination. /Daniel Carsten Ziegeler skrev: Ok, here is a simple plan to continue. Please note, that the current trunk has several new things: a new core which can be seen as a follow-up to 2.1.x, the blocks stuff and the maven build. We can use trunk as a direct follow-up to 2.1.x without blocks! As Bertrand suggested we should start with a fresh version number: 2.3. So the plan looks like this: 1. Release 2.1.9 by the end of march as discussed recently This includes freezing 2.1.x and really just doing important bug fixes there. 2. Copy trunk to a new place to continue the blocks development 3. Remove blocks stuff from trunk and use it as a base for 2.3 This includes: using the directory layout from 2.1.x and using the ant build sytem from 2.1.x 4. Sync 2.1.9 and 2.3: there are only a few things which still need to be synced. 5. Release 2.3m1 At the same time the blocks stuff can continue and we are not blocking any development. WDYT? Carsten
Re: [RT] a simple release plan
Daniel Fagerstrom wrote:
The blocks FUD
==
I'd like to remind once again that the blocks work doesn't destabilize
the traditional use of Cocoon the slightest, see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2. It
just cannot affect that as there are no dependencies from the
traditional parts to the blocks fw whatsoever. Concerning the OSGi
stuff it is not even part of the build yet.
So the idea that the block work should hinder anyone to work as usual is
just plain wrong.
M10N
What hinder people to work as usual is that the M10N isn't finished. Now
it isn't that hard to use Cocoon anyway as I described in the reference
above. But of course it would be nicer to be able to use Cocoon with
some blocks OOTB. If you don't want to take part in working on the
blocks fw and deployer and is impatient, it wouldn't be that hard to
write a plugin or an Ant task called from Maven that does the file
copying that is described in the reference above.
BTW, I'm quite surprised that you want to go back to the messy Ant build
from 2.1.x after having argued for building Cocoon with Maven for years.
Have you lost your faith in Maven?
Springification
===
Talking about destabilizing, a couple of weeks ago the trunk was usable
after the file copying referred to above. Actually it was so stable that
I developed a small customer application with it without any problems.
And AFAIU Reinhard have developed a large application in it. This is not
the possible anymore, after the Springification.
I tried to start a freshly checked out trunk together with the ajax,
form and template block after having copied the configuration files and
samples to cocoon-webapp as described above. The start page worked, but
all access to sub sitemaps gave null pointer exceptions, where the
TreeBuilder configuration can't be loaded. IIRC there where other things
that was reported that didn't work a couple of weeks ago as well.
I suggest that the container should be reasonably stable before even
thinking about doing any big moves.
--- o0o ---
Not surprisingly I'm -1 on your points 2 and 3. If you want to continue
in that direction which IMO represents a huge step back. I insist on
that you prove that it work and that you actually have the persistence
to carry it through, on a copy of the trunk in the whiteboard. After
that you need to cast a vote about making that the new trunk.
Also it should be much easier to update the Ant scripts than changing
the directory structure.
Anyway, why you would like to make such a huge effort in such an
backward pointing direction, instead of helping to finish the blocks
work or at least the M10N, is just beyond my imagination.
/Daniel
I agree with Daniel.
- o -
I want to add some thoughts to Daniel's idea of writing some Ant script for the
build: trunk has been mavenized and split up into many modules. The missing
thing is some tool that will create a web application out of a number of blocks.
In a world of real blocks that's the job of the deployer that I wrote.
If somebody has the need of writing some deployment tool without having to
understand blocks-fw, he could write an Ant script or an M2 Mojo that get some
kind of configuration which blocks should be installed:
configuration
blocks
blockorg.apache.cocoon:forms-impl:1.0-SNAPSHOT/block
blockorg.apache.cocoon:template-impl:1.0-SNAPSHOT/block
...
/blocks
/configuration
Then the mojo deploys them to the right place and takes the component
configuration out of it and puts it into /WEB-INF/xconf.
As M2 offers some Ant tasks to get access to M2 repos, this could be done with
Ant too.
I don't have the time right now and also don't have the urgent need for it - I
will concentrate on learning more about the configuration service, implementing
the OSGi contracts within the deployer and write a Daisy M2 plugin.
But of course I will help with my experiences with M2 mojo development. Also
checkout the cocoon-deployer-plugin module, which should give some
implementation hints.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
