Re: cocoon-xml-2.0.2 in dist?
We did a release of the xml sub project some time ago and that's the artifact for that. I don't see a reason to keep it; it's in the maven repo anyway. Carsten Vadim Gritsenko wrote Hey all, Anyone knows what's cocoon-xml-2.0.2 and what it is doing in the BINARIES download directory [1]? Unless there is a reason to keep it there, I plan to remove it. Vadim [1] http://www.apache.org/dist/cocoon/BINARIES/ -- Carsten Ziegeler cziege...@apache.org
Re: Team List Updates
Thanks Reinhard! Carsten Reinhard Pötz wrote On 01/13/2011 08:35 AM, Carsten Ziegeler wrote: Hi, it seems that the teamlists at: http://cocoon.apache.org/3.0/team-list.html http://cocoon.apache.org/team-list.html are out of date and need some updates. It would be great if someone could send me to emeritus. Thanks! I updated http://cocoon.apache.org/3.0/team-list.html. http://cocoon.apache.org/team-list.html will follow as soon as I find some time to finish my work on the Daisy reactivation (I'm half way through yet ...) so that a 'mvn site' rebuilds the docs. -- Carsten Ziegeler cziege...@apache.org
Team List Updates
Hi, it seems that the teamlists at: http://cocoon.apache.org/3.0/team-list.html http://cocoon.apache.org/team-list.html are out of date and need some updates. It would be great if someone could send me to emeritus. Thanks! Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [jnet] Threading issues
Reinhard Pötz wrote: Moving over this thread to dev. Carsten, any idea what could go wrong here? And, once I asked you why you used an InheritableThreadLocal instead of a ThreadLocal to store the list but can't remember. Can you explain it to me again? :-) I fear I can't help that much - the code has changed from my original version which did not use a list :) To be honest I don't know anymore why an InheritableThreadLocal was the better choicenow I guess because if you start a thread within the current execution, than this thread gets the same url handlers. With a simple ThreadLocal you don't get this. While having the same url handlers in the new thread is nice, it might create problems if the original thread executes before the newly started. But nevertheless this shouldn't result in concurrency problems as far as I can see. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE RESULT] Release cocoon-xml 2.0.2
Vadim Gritsenko wrote: On Dec 22, 2009, at 2:09 AM, Carsten Ziegeler wrote: Thanks for voting! I'll upload the artifacts asap. Hey Carsten, Were you able to upload it? All I could find is cocoon-xml-2.0.0 (and with -source jars for some reason in the BINARIES directory - weird): http://www.apache.org/dist/cocoon/BINARIES/ Ups, yes I was able to upload it to the maven repo: http://repo2.maven.org/maven2/org/apache/cocoon/cocoon-xml/2.0.2/ but apparently forgot to put it into the dist folder as well Will do that asap Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Closed: (COCOON-2275) [PATCH] Fix for Portal block and block samples
[ https://issues.apache.org/jira/browse/COCOON-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-2275. Resolution: Fixed Thanks for your patch, Klaus! I've applied it in revision 893125 [PATCH] Fix for Portal block and block samples -- Key: COCOON-2275 URL: https://issues.apache.org/jira/browse/COCOON-2275 Project: Cocoon Issue Type: Bug Components: Blocks: Portal Affects Versions: 2.2-dev (Current SVN) Reporter: Klaus Bertram Assignee: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: cocoon-portal-impl.patch, cocoon-portal-sample.patch There are many configurations inside the sample block and one inside the implementation. With this config changes the samples are working again -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2275) [PATCH] Fix for Portal block and block samples
[ https://issues.apache.org/jira/browse/COCOON-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned COCOON-2275: Assignee: Carsten Ziegeler [PATCH] Fix for Portal block and block samples -- Key: COCOON-2275 URL: https://issues.apache.org/jira/browse/COCOON-2275 Project: Cocoon Issue Type: Bug Components: Blocks: Portal Affects Versions: 2.2-dev (Current SVN) Reporter: Klaus Bertram Assignee: Carsten Ziegeler Fix For: 2.2-dev (Current SVN) Attachments: cocoon-portal-impl.patch, cocoon-portal-sample.patch There are many configurations inside the sample block and one inside the implementation. With this config changes the samples are working again -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE RESULT] Release cocoon-xml 2.0.2
Hi, the vote to release cocoon-xml 2.0.2 passed successfully with four binding +1 votes from Felix Knecht, Thorsten Scherler, David Legg, and Reinhard Pötz and one non-binding vote from Carsten Ziegeler. No other votes have been cast. Thanks for voting! I'll upload the artifacts asap. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.2
Anyone else? We need two more binding votes. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release cocoon-xml 2.0.2
Hi, I've assembled a release candidate for the xml sub project. This is just a maintenance release which adds the license and notice files to the jar and corrects some OSGi manifest headers. The code is the same as the 2.0.0 release. The release candidate can be found here: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.2/ Please cast your votes. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.2
+1 Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Assigned: (COCOON-2274) Include license info in the cocoon-xml bundle
[ https://issues.apache.org/jira/browse/COCOON-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned COCOON-2274: Assignee: Carsten Ziegeler Include license info in the cocoon-xml bundle - Key: COCOON-2274 URL: https://issues.apache.org/jira/browse/COCOON-2274 Project: Cocoon Issue Type: Improvement Components: - OSGi integration Reporter: Jukka Zitting Assignee: Carsten Ziegeler Priority: Minor It would be nice if the cocoon-xml bundle contained license information in META-INF/LICENSE and META-INF/NOTICE files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2274) Include license info in the cocoon-xml bundle
[ https://issues.apache.org/jira/browse/COCOON-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON-2274: - I've added the two files and also updated the header information in revision: 890383 Include license info in the cocoon-xml bundle - Key: COCOON-2274 URL: https://issues.apache.org/jira/browse/COCOON-2274 Project: Cocoon Issue Type: Improvement Components: - OSGi integration Reporter: Jukka Zitting Assignee: Carsten Ziegeler Priority: Minor It would be nice if the cocoon-xml bundle contained license information in META-INF/LICENSE and META-INF/NOTICE files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2274) Include license info in the cocoon-xml bundle
[ https://issues.apache.org/jira/browse/COCOON-2274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-2274. Resolution: Fixed Include license info in the cocoon-xml bundle - Key: COCOON-2274 URL: https://issues.apache.org/jira/browse/COCOON-2274 Project: Cocoon Issue Type: Improvement Components: - OSGi integration Reporter: Jukka Zitting Assignee: Carsten Ziegeler Priority: Minor It would be nice if the cocoon-xml bundle contained license information in META-INF/LICENSE and META-INF/NOTICE files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
New release of the xml subproject
Hi, I just fixed COCOON-2274 (https://issues.apache.org/jira/browse/COCOON-2274) which adds the license and notice files into the jar and fixes some OSGi header information. I would like to do a new release. Any comments/objections? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE RESULT] Release Cocoon Serializers Charset and Block
The vote to release Apache Cocoon Serializers Charsets 1.0.0 and Apache Cocoon Serializers Block 1.0.0 passed successfully with six +1 votes from: Carsten Ziegeler Felix Knecht Reinhard Pötz David Legg Thorsten Scherler Alfred Nathaniel I'll upload the artifacts asap. Thanks for voting! Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE RESULT] Release Cocoon Serializers Charset and Block
Carsten Ziegeler wrote: The vote to release Apache Cocoon Serializers Charsets 1.0.0 and Apache Cocoon Serializers Block 1.0.0 passed successfully with six +1 votes from: Carsten Ziegeler Felix Knecht Reinhard Pötz David Legg Thorsten Scherler Alfred Nathaniel Just to clarify, from the above six votes only five votes are binding. My vote is non-binding. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Admin rights for cocoon3 jira
Thorsten Scherler wrote: On Fri, 2009-10-09 at 10:59 +0200, Thorsten Scherler wrote: Hi all, I wanted to assign COCOON3-43 to myself but I cannot due to insufficient rights. Can somebody fix that for me. TIA Anybody? Pretty please. If I did everything correctly it should work now Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Cocoon Serializers Charset and Block
Reinhard Pötz wrote: Is the code that uses the HTTPRequest of any use (see EncodingSerializer#include)? Yes, this code can be used to include any (usuable non xhtml output) into the response without sending it through the pipeline. This is used (or would be used) for example by the cocoon portal to include portlet output directly into the response without requiring to transform the html output to xhtml just to get it through the pipeline. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release Cocoon Serializers Charset and Block
+1 Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Releasing serializers block
Reinhard Pötz wrote: Carsten Ziegeler wrote: During the release process I get errors as these two dependencies are missing. Path to dependency: 1) org.daisycms:daisy-maven-plugin:maven-plugin:1.0.0-alpha-2 2) org.apache.cocoon:cocoon-daisy-export-strategy:jar:1.0.0-SNAPSHOT Path to dependency: 1) org.daisycms:daisy-maven-plugin:maven-plugin:1.0.0-alpha-2 2) org.daisycms:daisy-java-adapter:jar:1.5.1.0-alpha-2 3) org.apache.avalon.framework:avalon-framework-api:jar:4.3 Any ideas? What Maven profiles do you activate? Everything mentioned here: http://cocoon.apache.org/1199_1_1.html Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Releasing serializers block
Reinhard Pötz wrote Please try again and only use the 'release' profile (= don't use 'daisy,localDocs,javadocs-script'). Let me know if that works for you. Yes, thanks that works. I'll start the vote soon :) Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release Cocoon Serializers Charset and Block
Hi, please vote on a first release of these two artifacts: Apache Cocoon Serializers Charsets 1.0.0 http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-serializers-charsets/1.0.0/ and Apache Cocoon Serializers Block 1.0.0 http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-serializers-impl/1.0.0/ The first artifact is a general purpose library with the basic code for the serializers. The block uses this lib to add some new serializers to Cocoon. Please cast your votes. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Releasing serializers block
During the release process I get errors as these two dependencies are missing. Path to dependency: 1) org.daisycms:daisy-maven-plugin:maven-plugin:1.0.0-alpha-2 2) org.apache.cocoon:cocoon-daisy-export-strategy:jar:1.0.0-SNAPSHOT Path to dependency: 1) org.daisycms:daisy-maven-plugin:maven-plugin:1.0.0-alpha-2 2) org.daisycms:daisy-java-adapter:jar:1.5.1.0-alpha-2 3) org.apache.avalon.framework:avalon-framework-api:jar:4.3 Any ideas? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Releasing serializers block
Reinhard Pötz wrote: Carsten Ziegeler wrote: Hi, I would like to release the 2.2 version of the serializers block (consisting of two modules). Is anything preventing us from releasing this? No I don't think so. After rereading the original thread about this block (see http://cocoon.markmail.org/message/z63kh2sx3u4spxo7) I just wonder if the mentioned Xalan bugs haven't been fixed in the meantime. Yes, maybe - but as the last release is very old, I would not count on that. The second question that came to mind was whether we should make the serializers-charset module an OSGi bundle. And we should change the namespace to org.apache.cocoon.serializers.* for both modules. +1 for OSGi, I'll do that I'm not sure for the packages as this might be incompatible to 2.1.x? What's the procedure to release the block? http://cocoon.apache.org/1199_1_1.html describes the technical details. You should be able to use http://repo1.maven.org/maven2/org/apache/cocoon/cocoon/8/cocoon-8.pom as parent POM (but I'm not sure about this because usually we use the cocoon-blocks-modules as parent POM). Ah ok, thanks! We also need to test that the serializers-impl Avalon sitemap components work with Cocoon 2.2 or even better, migrate them to Spring (but I don't consider the migration being absolutely necessary). Yes, that would be great :) I think I tested this a long time ago...but hopefully I'll be able to do that again After releasing it I can help out with updating the documentation - maybe you can add a few paragraphs to http://cocoon.zones.apache.org/daisy/cdocs/g1/g3/g5/1252.html. Cool, thanks! Carsten -- Carsten Ziegeler cziege...@apache.org
Releasing serializers block
Hi, I would like to release the 2.2 version of the serializers block (consisting of two modules). Is anything preventing us from releasing this? What's the procedure to release the block? Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [2.2] ThreadLocal use in PoolableProxyHandler
Alexander Daniel wrote: Does somebody know why ThreadLocal is used in PoolableProxyHandler [1] for the componentHolder in Cocoon 2.2? Sure :) Whenever components are taken out of the pool they need to be put back somehow, so they are available for other clients again. We use a thread local which is cleared when the request finishes, so all used components get back into the pool. Carsten Thanks, Alex [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java -- Carsten Ziegeler cziege...@apache.org
Re: [2.2] ThreadLocal use in PoolableProxyHandler
Alexander Daniel wrote: On 03.07.2009, at 10:41, Carsten Ziegeler wrote: Alexander Daniel wrote: Does somebody know why ThreadLocal is used in PoolableProxyHandler [1] for the componentHolder in Cocoon 2.2? Sure :) Whenever components are taken out of the pool they need to be put back somehow, so they are available for other clients again. We use a thread local which is cleared when the request finishes, so all used components get back into the pool. Thanks for the answer Carsten. What you describe is done by the destruction callback mechanism of Spring. But why can't we simply use a direct reference [2] to the component? Why is a ThreadLocal used as key to the component? Hmm, not sure if I understand you correctly. The poolable factory returns a single instance to spring which is the proxy - spring has no knowledge of poolable components. Therefore the proxy together with a thread local is used to internally forward the method calls to instances from the pool. There is a separate instance per thread - otherwise you would run into multi-threading issues as the same instance would be used across requests. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [2.2] ThreadLocal use in PoolableProxyHandler
Alexander Daniel wrote
PoolableFactoryBean [2] creates a new PoolableProxyHandler instance [1]
for each pooled component used in a pipeline, i.e. it will not be shared
across different requests. Therefore I do not understand the use of
ThreadLocal.
Yes, you're right for sitemap components - but this isn't true for any
other component. Imagine a singleton component using a poolable. The
singleton is used by multiple threads and therefore each thread
requires an own instance
Now, this is not optimal and actually it's legacy code - it is only used
for old Avalon components.
Carsten
Alex
[1]
public Object getObject() throws Exception {
return Proxy.newProxyInstance(this.getClass().getClassLoader(),
this.interfaces,
new PoolableProxyHandler(this));
}
[2]
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/src/main/java/org/apache/cocoon/core/container/spring/avalon/PoolableFactoryBean.java
--
Carsten Ziegeler
cziege...@apache.org
[jira] Closed: (COCOON-1959) o.a.c.environment.Request'setParameter()
[ https://issues.apache.org/jira/browse/COCOON-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-1959. Resolution: Won't Fix This one has been open for a long time, so I think it's ok to close this know o.a.c.environment.Request'setParameter() Key: COCOON-1959 URL: https://issues.apache.org/jira/browse/COCOON-1959 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.1.10, 2.2 Reporter: Mark Lundquist Assignee: Carsten Ziegeler Priority: Minor I would like to add a setParameter() method to o.a.c.environment.Request. I think this would be useful for setting up internal forwards. Please let me know if (a) this isn't going to work the way I want it to, or (b) there's some other reason not to do this, e.g. oh, we're changing everything and that class is going away :-). If I don't hear any -1, I'll write a patch to do this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2071) Option to turn off pooling for components (probably faster on new JVMs and simpler debugging)
[ https://issues.apache.org/jira/browse/COCOON-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON-2071. Resolution: Won't Fix This has been open for a long time with no further action, so I'll close this Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) - Key: COCOON-2071 URL: https://issues.apache.org/jira/browse/COCOON-2071 Project: Cocoon Issue Type: Test Components: - Components: Sitemap Affects Versions: 2.2 Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler Priority: Minor Attachments: disable-pooling-config.patch This is a patch that makes the pooling of components/beans optional: by setting this in the applicationContext.xml !-- Activate Avalon Bridge -- avalon:bridge pooling=false/ it is possible to turn off pooling completely. The idea is to start testing performance differences between pooling and non-pooling. The default value for the pooling option is true, so existing configurations without the attribute set will behave as before when this patch is applied. Pooling was introduced back then when creating a new object in Java was slow and re-using of existing objects was faster. Since Java 1.4 this is no longer the case, creating new objects is said to be even faster than malloc() in C. Because pooling needs a recycle() method (to reset internal stuff before reuse) and more calls, including some AOP and Proxy class stuff to add pooling, it is worth to check what is faster nowadays. One thing that always annoys me during debugging is that the AOP stuff adds like 4-5 additional calls when accessing a pooled component in the stacktrace - code that you cannot step into, because it has no java source. Removing pooling completely would make the Cocoon architecture (especially the runtime architecture) much simpler. My idea is that Cocoon users can test the performance difference on their various systems to get actual results. WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [C3] Refactoring the SAX module
Reinhard Pötz wrote: in your original mail you mentioned that your patch also fixed some bugs. Do you remember what it was? not concrete :( I'll go through the code and try to find the place. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [C3] Refactoring the SAX module
Carsten Ziegeler wrote: I'll go through the code and try to find the place. Ok , I couldn't find them anymore :( Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [C3] Refactoring the SAX module
Hi, I'll drop my suggestions and close the bug. Thanks for the feedback Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Closed: (COCOON3-22) Remove XMLConsumer interface
[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON3-22. --- Resolution: Won't Fix Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: cocoon-3.patch, cocoon-stax.patch, StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-22) Remove XMLConsumer interface
[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674718#action_12674718 ] Carsten Ziegeler commented on COCOON3-22: - Ah yes, it doesn't cover this as I don't have Java 6 on my machine :( But I can update the patch Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: cocoon-3.patch, StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [C3] Refactoring the SAX module
Reinhard Pötz wrote: The feedback of our student group was rather the opposite. I'm pretty sure that it helps to understand Cocoon 3 if all different pipeline component implementations follow the same logic. Hmm, ok, I don't think so, so let's just agree that we disagree here. But of course my survey isn't really scientific ... I haven't even done a survey but just did test myself :) From the past I know that many people were confused by all the interfaces and abstract classes we had in Cocoon 2.x, but maybe that's different with a new C3. I'm not fully convinced yet. I will have a look at it again when I can apply the patch and can build Cocoon. I have some (internal) code that uses cocoon-sax and I want to understand all effects. Apart from the stax stuff, it builds (at least for me) and the tests run. I'll add a second patch which fixes the stax stuff. I'm also preparing a project proposal (GSoC, Vienna-based student groups) about Cocoon profiling which relies on Spring AOP and I have to think about the influence of not having SAXConsumer and SAXProducer anymore. Hmm, I think this should still be possible. Now, to be honest, I find the whole situation not very comfortable at the moment. There are only a few contributing to C3 and nearly no other comments. My intention is to have a small, nice and easy, pipeline api which allows me to build sax pipelines. And I want to have as less dependencies and as less stuff in their to make it understandable as possible. I don't think that the symmetrie to the other implementations helps us. But that's of course my personal opinion. I think we (Steven, you, the Vienna-based students and myself) have a opinion and I guess it is based on/influenced by our experience and we are somehow stuck in our thinking. So it would be great if others could voice their opinion. Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Updated: (COCOON3-22) Remove XMLConsumer interface
[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON3-22: Attachment: cocoon-stax.patch Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: cocoon-3.patch, cocoon-stax.patch, StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[C3] Refactoring the SAX module
Hi, as part of COCOON3-22 I've refactored the whole SAX module and removed a lot of classes :) Before committing these changes I would like to discuss them (I can provided a patch but not sure if this works). Ok, the aim is to reduce the number of interfaces and abstract classes as much as possible. The o.a.c.sax packages contains - SAXPipelineComponent - the marker interface for all sax components - AbstractSAXGenerator, AbstractSAXSerializer, AbstractSAXTransformer - the base classes to simplify implementation of these components - AbstractSAXProducer - base class for AbstractSAXGenerator and AbstractSAXTransformer That's it - this creates imho a clean package and provides a good base for implementing own sax based components. Ok, I left o.a.c.sax.component the way it is atm (of course adapted the implementations) And o.a.c.sax.util only contains TransformationUtils and XMLUtils. The former adapter class in this package is replaced by SAXPipe from cocoon-xml (our 2.2 subproject). I'Ve added a copy of this class to cocoon-sax for the moment to not rely on a snapshot of cocoon-xml here. I also fixed javadocs and some bugs in the implementations :) I know that these changes will brake the symmetrie between the other implementations (Stax mainly) - but on the other hand it gives a nice and easier structure to implement components. People comming from 2.x who want to implement a component just pick up AbstractXYZ as a base and are done. And as these abstract classes are deduced to the minimum it's imho much easier to understand what's going on. I would go one step further and also remove the AbstractSAXProducer class and copy the code to the two using classes to make the hierarchy even simpler. But that's not a must :) So, what do you think? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [C3] Refactoring the SAX module
Steven Dolg wrote: Just random thoughts (and I must admit I haven't thought about the changes in detail): * Extending some abstract classes is all that was necessary all the time. Yepp. Getting rid of some of the interfaces implemented by those abstract classes actually changes nothing for a developer but makes things like AOP (at least sometimes) a lot harder. Maybe, but I don't think in this case. * Forcing a developer to add his classes to our class hierarchy eliminates any possibility of building his own class hierarchy and implementing the interfaces directly (this might not be necessary in the most cases, but I see no reason to eliminate this option completely) Oh, that's still possible of course. * Duplicating code to make the class hierarchy even simpler (whatever that means) seems like a pretty bad idea IMO. Code duplication has almost never done anything good for me (besides being quick dirty - which is usually just dirty and not quick at all if you intend to work with the code for quite some time). LOL - sorry, couldn't resist - now, I totally agree with you in general, but in this case it's duplication of never changing code - it might be a bad idea, but on the other hand, as I repeatedly said: there are imho already a lot of interfaces and abstract classes involved. And this is confusing to new people. * Replacing the SAXConsumerAdapter with the SAXPipe means it cannot be used as a surrogate destination for a SAXTransformer or adapter for a ContentHandler (which was the intention behind this class) - so how can it actually replace it (or has the contract between SAXProducer and SAXConsumer changed)? Yes, it changed - there is no consumer and producer anymore. The SAXPipe implements ContentHandler and that's all what is required. * Without any more detail it's impossible to fathom the meaning/implications of those changes. Ok, I've attached the patch to https://issues.apache.org/jira/browse/COCOON3-22 So is this about having a developer still extending AbstractSAXGenerator, AbstractSAXSerializer, AbstractSAXTransformer (which all exist now) but making the class hierarchy above (as in towards java.lang.Object) less deep/wide by removing interfaces/abstract classes implemented/extended by those classes? Yes, it's about removing ballast - now, as you said, for the average developer there are no real changes as there are still the abstract classes of course. And sorry for asking again, but what's the rationale behind reduce the number of interfaces and abstract classes as much as possible? No problem, the rational is to make this beast easier to understand. Look at the current sax module and browse the hierarchy of interfaces and abstract classes. I know Cocoon and most of this stuff for years, but it took me some time to find out what is there and why and how things work. Maybe it's me getting old, but I hope not :) So why not simply having just the stuff there which is really needed? Try to explain the difference between the existing abstract classes/interfaces :) HTH Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Updated: (COCOON3-22) Remove XMLConsumer interface
[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON3-22: Attachment: cocoon-3.patch Proposed patch Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: cocoon-3.patch, StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [C3] Refactoring the SAX module
Steven Dolg wrote Just realized there is no SAXConsumer any more. So how does the linking between SAX components work? AbstractSAXProducer will accept an AbstractSAXTransformer or AbstractSAXSerializer? Or operate directly against ContentHandler (which would explain the SAXPipe thingy)? Yes, it's just ContentHandler - and this alone is imho really an improvement. But once you do this, you see that you can simplify other things and that's what the patch is all about. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Documentation System [was: Spring Configurator Docs]
Robby Pelssers schrieb: Hi Carsten, It's a bit hidden, but if you click on the link Cocoon2.2 under versions, you will get the overview page with a link to the spring configurator. Hmm, but this opens http://cocoon.apache.org/subprojects/configuration/1.0/1329_1_1.html which allows me to just download the configurator, but I still can't see the docs :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Documentation System [was: Spring Configurator Docs]
Grzegorz Kossakowski wrote: Grzegorz Kossakowski pisze: Hi Carsten, Apparently, there is a mess with configurator docs. Here you can see that there are no 2.0 docs: http://svn.eu.apache.org/repos/asf/cocoon/site/site/subprojects/configuration/ Even if we have a link to them here: http://cocoon.apache.org/subprojects/ This looks like someone forgot to regenerate docs after the release. Anyway, this does not explain why docs are not reachable even if I remember they were. I'll try to ask git bisect for a faulty commit. Will report my findings. Ok, I found the faulty change: http://cocoon.zones.apache.org/daisy/cdocs/g2/g7/1329/version/5/diff?otherVersion=6 As you can see, this change removed the whole table that linked to documentation of Configurator. I have no clue on this change so I guess we'll need to ask Reinhard what's going on. As a side-note: I can feel your pain with our current documentation system. I don't think it's fundamentally flawed but little bit not maintained-enough. There are areas for improvements. The biggest I can see is removing mismatch between version information stored in svn and daisy. Daisy lacks any information about our artifacts we are releasing which leads to annoying problems. I think there are too many steps involved in getting something out - adding chapters is really a pain; and as we see above we're loosing content and nearly noone notices this and nearly noone knows how to restore this. And still I think the resulting urls are really not pretty urls, I really would prefer something like http://cocoon.apache.org/spring-configurator/index.html But again, maybe it's just me. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Documentation System [was: Spring Configurator Docs]
hepabolu wrote: As one of the initiators of the current Daisy documentation route, I am feeling the same pain. My current use of Cocoon is 0% although I can't get myself to unsubscribe from the lists. ;-) The current pace of development is too quick to help out in documentation if you're not heavily involved in the project. My initial ideas about this setup was that it's fairly easy and quick to open up a page in Daisy and start adding documentation. That way the chances of actually adding documentation increase. Anything that takes a lot of time will spoil the chance of actual writing. Don't think that each page in Daisy should immediately be added to the general site, but use the update frequency to let it simmer and improve the quality. Once you have a page, adding/editing the docs is easy with Daisy - that's fine; but adding new pages or new folders has always been a mystery for me. There are some docs on how to do this, but even following them is rather complicated. Anyway, if the people who contribute to the docs are fine with this setup, its great. In most of the other Apache projects I'm working on, we're using Confluence which has the important advantage that the installation is supported by infra. It would be great if someone could find out why the docs for the spring configurator are not linked anymore on our site (or I'm still too dumb to find the links). Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Spring Configurator Docs
Hi, can someone point me to our online docs of the spring configurator? I wasn't able to find it.. :( Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Spring Configurator Docs
Chirathuru, Nagaraju wrote: Hi Carsten, Here it is. http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurat or/2.0/1304_1_1.html Ah, thanks! Is there a link from the main or the sub projects site? All I see is this: http://cocoon.apache.org/subprojects/configuration/1.0/1329_1_1.html without any pointers to the docs. Carsten Cheers Nagaraju Chittathuru -Original Message- From: Carsten Ziegeler [mailto:cziege...@apache.org] Sent: Thursday, February 12, 2009 1:35 PM To: Cocoon-Dev Subject: Spring Configurator Docs Hi, can someone point me to our online docs of the spring configurator? I wasn't able to find it.. :( Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Spring Configurator Docs
Robby Pelssers wrote: Speaking of docs... I really have difficulties finding documentation on the new cocoon2.2 site. The 2.1 was much more structured in my opinion. There probably is a lot well documented but it's a nightmare to find the information back. The menu only has a few links to get started but there is no clear way of navigating to the other pages... Hmm, yes I agree and I had the same feeling when trying to edit/update docs back in the good old days :( May be it's time to use something like confluence for C3 Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE RESULT] Release cocoon-xml 2.0.0 [was Re: [VOTE] Release cocoon-xml 2.0.0]
Reinhard Pötz wrote: Carsten Ziegeler wrote: The vote to release cocoon-xml 2.0.0 finished successfully with three binding +1 votes (from David Legg, Reinhard Pötz, and Carsten Ziegeler) and one non binding +1 vote from Andreas Pieber. No other votes were cast. Thanks for your support! I'll continue with the release upload asap. Great! As soon as the artifacts are available, I will apply COCOON3-26 (with some minor modifications). Cool, it's available now. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Cocoon-xml dependency on xml-apis
Reinhard Pötz wrote: Does cocoon-xml still need a dependency on xml-apis? AFAIU with Java 5 the Jaxp API is part of the JDK and we don't need to add it ourselves, do we? Yes, you're right - I removed it in trunk. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.0
Andreas Pieber wrote: I've reviewed them, and +1 from me, but I'm not sure if I'm authorized to vote? Hi Andreas, everyone can vote and we are happy about every feedback from the community; so your vote is really appreciated. The final vote counting however takes only binding votes into account; binding votes are votes from the PMC members. HTH Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE RESULT] Release cocoon-xml 2.0.0 [was Re: [VOTE] Release cocoon-xml 2.0.0]
The vote to release cocoon-xml 2.0.0 finished successfully with three binding +1 votes (from David Legg, Reinhard Pötz, and Carsten Ziegeler) and one non binding +1 vote from Andreas Pieber. No other votes were cast. Thanks for your support! I'll continue with the release upload asap. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.0
David Legg wrote: I'm not sure about the utility of the SAXUtils class. I think using them will tend to obfuscate any code that uses it but it's a minor point. Hmm, may be - we can improve this over time. The code there is years old :) I'm not too happy about the various 'protected' fields like the ones in SAXBuffer.java or DOMBuilder.java etc. It would be all too easy to write code that accidentally abused these fields. I suppose this could be fixed later by making them private. Yes, that's right. Here's my +1 Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.0
Hi, has anyone else time to review the release? So far we only have two votes. Thanks Carsten Carsten Ziegeler wrote: Hi, I've assembled a first release candidate for the new xml sub project containing useful stuff for dom and sax handling. The module is small and focused and could be used as a utility lib for C3. The release candidate can be found here: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.0/ Please cast your votes. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.0
+1 Carsten Carsten Ziegeler wrote: Hi, I've assembled a first release candidate for the new xml sub project containing useful stuff for dom and sax handling. The module is small and focused and could be used as a utility lib for C3. The release candidate can be found here: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.0/ Please cast your votes. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.0
Reinhard Pötz wrote: Carsten Ziegeler wrote: Hi, I've assembled a first release candidate for the new xml sub project containing useful stuff for dom and sax handling. The module is small and focused and could be used as a utility lib for C3. The release candidate can be found here: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.0/ Please cast your votes. +1 Just wondering, why is it 2.0.0 and not 1.0.0? Yes, I wondered this myself after I did the releaseI had a reason for not starting with 1.0.0, but that's too long ago to remember. As it doesn't really matter in the end, I decided to continue :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.0
Reinhard Pötz wrote: Carsten Ziegeler wrote: Hi, I've assembled a first release candidate for the new xml sub project containing useful stuff for dom and sax handling. The module is small and focused and could be used as a utility lib for C3. The release candidate can be found here: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.0/ Please cast your votes. AFAICT, the artifacts are ok (I've just successfully integrated it with C3) but the release artifacts are not signed with your PGP key. Urgs, yes you're right of course - will fix this later today Thanks Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Release cocoon-xml 2.0.0
Carsten Ziegeler wrote: Reinhard Pötz wrote: Carsten Ziegeler wrote: Hi, I've assembled a first release candidate for the new xml sub project containing useful stuff for dom and sax handling. The module is small and focused and could be used as a utility lib for C3. The release candidate can be found here: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.0/ Please cast your votes. AFAICT, the artifacts are ok (I've just successfully integrated it with C3) but the release artifacts are not signed with your PGP key. Ok, artifacts are signed now. Carsten -- Carsten Ziegeler cziege...@apache.org
[VOTE] Release cocoon-xml 2.0.0
Hi, I've assembled a first release candidate for the new xml sub project containing useful stuff for dom and sax handling. The module is small and focused and could be used as a utility lib for C3. The release candidate can be found here: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.0/ Please cast your votes. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [RT] C3: Cleaning up SAX module
Andreas Pieber wrote: I'm not convinced that removing XProducer and XConsumer will resolve all problems described by you since you still need a reference to Cocoon (e.g. for PipelineComponent and Producer/Consumer). Yes, you got me :) One possibility to get rid of all references could be the spring framework. POJOs with a ContentHandler and an setConsumer(Object) method could be (very easily) described in XML and wrapped at runtime to real PipelineComponents. Yes, but if I really want to do this, I can do this regardless if we have SAXConsumer (XMLConsumer) or not. An other option would be to let XProducer and XConsumer (maybe renaming them to SAXProducer and SAXConsumer :) ) (Yes, we should rename them and I think we already agreed on this on) and just weaken the conditions. The components simply check for an ContentHandler/LexicalHandler as they require. With this approach you let the decision to the developer if he like to simply inherit from the X-Interfaces and has an SAXPipelineComponent, a ContentHandler and so on at once or do it on his own. WDYT about this approach? Hmm, not sure :) Seems like a wrong compromise to me :) Either we really want these interfaces for symmetrical reasons (which I think is not worth doing it and given the different between the formats itself doesn't help) or if we want the simplest approach for each type (xml, dom, stax). I would vote for the second approach. Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Commented: (COCOON3-22) Remove XMLConsumer interface
[ https://issues.apache.org/jira/browse/COCOON3-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668370#action_12668370 ] Carsten Ziegeler commented on COCOON3-22: - Ok, having worked with the xml consumer interface for years now, I came to the conclusion that things get much simpler if you just rely on content handler It makes using the sax stuff much easier and more convenient - I don't think that we need to keep the stax stuff and other impl in sync just for the sake of having them in sync. But please let's do this discussion in the mailing list - i've started an RT some days ago about this topic and so far got only positive response (from Sylvain) Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Attachments: StAX-classes.png Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGi integration (again)
Juan José Vázquez Delgado wrote: Hi, I could imagine a future version of Lenya to use Sling for the repository management. I wouldn't like to give up Cocoon's pipelining and XML processing capabilities, though. Me neither :) I'm not sure in which way Sling and Cocoon would cooperate from a request processing point of view (I imagine that Sling resources can include the output of Cocoon pipelines, which process data generated by other resources), but I guess having the option to deploy Cocoon blocks/modules as OSGi bundles would be a good starting point. For our products I've written a simple pipeline api (and impl) which post processes the output from Sling. My intention is to do exactly this with C3. I´ve written a proof of concept with a Sling Servlet using the Cocoon pipeline api to get the response. This proof was ok but I´m thinking about a more natural Cocoon/Sling integration. IMHO, a pipeline, even a sitemap, would be as a script in Sling. Wow, great - what do you think about committing this into the Sling whiteboard? So we can use this as a prototype and base for further discussions. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [RT] C3: Cleaning up SAX module
Andreas Pieber wrote: I really like the idea of having a common base architecture between all components (sax, stax, ...). I'm not sure if we really have to hold them in sync since its more a basic architectural decision to rely on an a special Producer/Consumer interface than a syncing task. But I just wanted to point out that we sacrifice this basic architecture (existing at the moment) if we remove XConsumer/XProducer. I doesn't want to say that we should not do it, if there are more advantages than drawbacks :) Ok, usually I'm for a unified architecture if it's possible. But in this case I think it doesn't give any advantage. The xml handling differs a lot between dom, sax and stax. So even if you find interface with similar names (xyzProducer, xyzConsumer) they are completly different and have to be used differently when it comes to implementing own components. Years ago we decided in Cocoon to introduce the XMLConsumer interfaces. During the years, it rather proofed that this interface creates unnecessary trouble. For example you get some third party stuff implementing just content handler, you have to wrap it first. Or if you want to write general sax components that work with and without Cocoon, you have a dependency on Cocoon just for this interface. In the last years I followed the approach the jaxp api follows: just use content handler, and check if the object also implements content handler. This really simplifies the impl and the handling, makes integrating other stuff easy and doesn't create unnecessary dependencies. I'm very sorry for that but the last days in January are always very painful for Austrian students... No problem :) we're now having this discussion here and that's all that counts. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: OSGi integration (again)
Andreas Hartmann wrote: Hi Daniel, Daniel Fagerstrom schrieb: As some of you might have seen in the SVN logs, I have started to work on making Cocoon work under OSGi again [1]. are you still working on this? I'd be interested in deploying Cocoon in an OSGi environment. I just checked out the osgi directory from the whiteboard. After updating the version of the Cocoon artifact I'm running into several build issues. The POM files under commons contain the following parent declaration: parent groupIdorg.apache.felix.commons/groupId artifactIdbuild/artifactId version0.9.0-incubator-SNAPSHOT/version /parent Is this still up to date? I couldn't find anything about a build artifact in the Felix commons sub-project. This is definitly not up to date :( I can't speak about C2, but my intension is to enable C3 for OSGi (whatever that means in the end). Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (COCOON3-22) Remove XMLConsumer interface
Remove XMLConsumer interface Key: COCOON3-22 URL: https://issues.apache.org/jira/browse/COCOON3-22 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Fix For: 3.0.0-alpha-2 Remove XMLConsumer interface; relying on a content handler which might optionally implement lexical handler is sufficient and simplifies the module -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: OSGi integration (again)
Andreas Hartmann wrote: BTW, to illustrate my intentions: I could imagine a future version of Lenya to use Sling for the repository management. I wouldn't like to give up Cocoon's pipelining and XML processing capabilities, though. Me neither :) I'm not sure in which way Sling and Cocoon would cooperate from a request processing point of view (I imagine that Sling resources can include the output of Cocoon pipelines, which process data generated by other resources), but I guess having the option to deploy Cocoon blocks/modules as OSGi bundles would be a good starting point. For our products I've written a simple pipeline api (and impl) which post processes the output from Sling. My intention is to do exactly this with C3. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [RT] C3: Cleaning up SAX module
Sylvain Wallez wrote: Now we should also consider javax.xml.sax.SAXResult that holds a ContentHandler and an optional LexicalHandler, and has an interesting SystemId property that could be used to propagate a base URI from one component to the next one without relying on an external resolver context. Ah interesting idea. And the fact that SAXResult _holds_ the handlers rather than implementing the interfaces can in many cases avoid a level of wrapping as the one mentioned above. Yepp But the properties in SAXResult are mutable and the javadocs don't specify when these properties can change, i.e. if a producer should call getHandler() every time it needs to produce events of if the value can be kept for the whole stream of events, even if I think the second case is the most often used. Ah too bad :( So in the end, using a ContentHandler that optionally implements LexicalHandler looks like the simplest and most robust solution. Yes, it seems better than relying on a not clearly specified assumption (btw, if the sax result just has a content handler, this should be tried to be casted to a lexical handler as well, so we are in good company) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [RT] Using the xml subproject in C3
Reinhard Pötz wrote: Carsten Ziegeler wrote: Hi, I think we should use the new xml subproject (containing sax and dom utility classes) in C3. If noone objects, I could do the changes in the next days. Do you have any plans for a release of the xml subproject? I'm asking because I'd like to release Cocoon 3 alpha-2 in the next weeks. I don't have a plan, but I think we can release it today as this code is tried and trusted for years. It's too long ago since the last time I did a cocoon release...is there anything else to do, then using the maven plugin to release, call the vote and upload? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [jira] Commented: (COCOON3-14) Use generics for pipeline assembly
If I only had known that this simple enhancement starts these discussions :) Now, my understanding of C3 is that it is kind of a prototype (the current code of course works perfectly and is stable, so marking this a prototype might seem wrong from this pov). We can use this as a good base for discussions, especially as this is a working solution. So I think it makes totally sense to patch/enhance parts of C3 and see where this leads us; I think it's near to impossible to discuss the whole desing theory of C3 in this mailing list, agree on something and then come up with the implementation. This would only work during a f2f get together, which seems to be out of question atm. So, again, let's use the current code as a base and discuss single points one after the other (although some points may have influence on other points). As we're still doing alpha releases, in theory we can change everything - but I don't think that this is required :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [C3] Question about the Consumer
Steven Dolg wrote: Michael Seydl schrieb: What purpose or intention has it that the Consumer isn't a PipelineComponent? Actually that's just a design flaw we haven't fixed yet. Of course it should be a PipelineComponent. So let's fix this :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [c3] Towards alpha-2
Reinhard Pötz wrote: I'd like to release Cocoon 3 alpha-2 very soon. The open tasks are Great, . rename SAX components and interfaces (i.e. follow the naming scheme that is used in the stax module) which naming scheme is this? SAXSomething I hope as this is the way everyone else is writing these class names. . integrate the final version of the stax module which will contain a SAX wrapper, more samples and documentation . use the Cocoon XML subproject (requires an official release) . apply COCOON3-14 (Use generics for pipeline assembly) Other tasks that I'd like to see completed but I won't wait for are: . find a solution for a pipeline input/output contracts (http://article.gmane.org/gmane.text.xml.cocoon.devel/79362) . I've a working prototyp of the integration of JAX-RS (using Jersey) with Cocoon 3. If there are no objections and I have enough time to finish it, I'd like to add it to the cocoon-rest module. Comments? +1 Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (COCOON3-15) Use Java 5 Regex instead of internal sun classes
Use Java 5 Regex instead of internal sun classes Key: COCOON3-15 URL: https://issues.apache.org/jira/browse/COCOON3-15 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sitemap Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 3.0.0-alpha-2 The wildcard matcher helper uses internal sun classes which makes the module fail during compilation on my mac osx; jdk 5 The use of the internal classes should be replaced with the java.util.regex classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON3-15) Use Java 5 Regex instead of internal sun classes
[ https://issues.apache.org/jira/browse/COCOON3-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler closed COCOON3-15. --- Resolution: Fixed Changed in revision: 737809 Use Java 5 Regex instead of internal sun classes Key: COCOON3-15 URL: https://issues.apache.org/jira/browse/COCOON3-15 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sitemap Affects Versions: 3.0.0-alpha-1 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: 3.0.0-alpha-2 The wildcard matcher helper uses internal sun classes which makes the module fail during compilation on my mac osx; jdk 5 The use of the internal classes should be replaced with the java.util.regex classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COCOON3-14) Use generics for pipeline assembly
Steven Dolg wrote Is it just me or is the patch you applied not really complete? Because doing PipelineSAXPipelineComponent pipeline = new NonCachingPipelineSAXPipelineComponent(); pipeline.addComponent(new StringGenerator(xmlInput)); pipeline.addComponent(new SchemaProcessorTransformer(this.getClass().getResource(/test.xsd))); pipeline.addComponent(new XMLSerializer()); yields a compile error for the last line, because XMLSerializer is not a o.a.c.p.c.s.SAXPipelineComponent. Upps, it's an oversight, sorry. On the other hand, the class hierarchy of the whole SAX module is rather messy IMO... Yes, that's what I thought as well :) But I saw you opened a bug for this. so let's discuss it there. Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Commented: (COCOON3-16) Fix the class hierarchy of org.apache.cocoon.pipeline.component.Consumer
[ https://issues.apache.org/jira/browse/COCOON3-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667598#action_12667598 ] Carsten Ziegeler commented on COCOON3-16: - We should use the SAXBuffer from cocoon-xml instead and do we really need NullXMLConsumer? I think we can go without an XMLConsumer completly and just really on ContentHandler. I'll commit with an RT about that in the list. Fix the class hierarchy of org.apache.cocoon.pipeline.component.Consumer Key: COCOON3-16 URL: https://issues.apache.org/jira/browse/COCOON3-16 Project: Cocoon 3 Issue Type: Bug Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-1 Reporter: Steven Dolg Assignee: Steven Dolg Fix For: 3.0.0-alpha-2 Attachments: consumer.patch The interface o.a.c.p.c.Consumer does not extend o.a.c.p.c.PipelineComponent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[RT] C3: Cleaning up SAX module
Hi, I think we can reduce the number of interfaces in the SAX module by just removing XMLProducer and XMLConsumer. XMLProducer is just a marker interface combining Producer and SAXPipelineComponent, so we can just remove it. XMLConsumer combines LexicalHandler, ContentHandler and Consumer. I think we can remove this and just rely on ContentHandler for chaining sax components. When sax components are chained, they can simply check if the next component implements LexicalHandler as well or not. With this simple improvement we can also remove the XMLConsumerAdapter. WDYT? Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] Created: (COCOON3-14) Use generics for pipeline assembly
Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated COCOON3-14: Attachment: generics.patch Patch Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666527#action_12666527 ] Carsten Ziegeler commented on COCOON3-14: - Why does your example from above not work with generics? Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666541#action_12666541 ] Carsten Ziegeler commented on COCOON3-14: - Hmm I still don't so :) As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666541#action_12666541 ] cziegeler edited comment on COCOON3-14 at 1/23/09 5:46 AM: -- Hmm I still don't think so :) As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). was (Author: cziegeler): Hmm I still don't so :) As far as I understood all the discussions it is now allowed to mix sax with stax or dom components in a pipeline, they are required to use the eventing (if you regard dom as one single big event). Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON3-14) Use generics for pipeline assembly
[ https://issues.apache.org/jira/browse/COCOON3-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1210#action_1210 ] Carsten Ziegeler commented on COCOON3-14: - Yes, even with this patch it's still possible to mix different component types and yes, we have to introduce new marker interfaces :) (and yes it was me how mentioned that there are too many interfaces already...), but if you're just interested in one component type, e.g. sax, then it's just one additional interface. So if noone objects I'll apply the patch in the next days. Use generics for pipeline assembly -- Key: COCOON3-14 URL: https://issues.apache.org/jira/browse/COCOON3-14 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Reporter: Carsten Ziegeler Assignee: Cocoon Developers Team Attachments: generics.patch This is a simple patch to add generics to the pipeline interface and impl. With additionally introducing marker interfaces for the component types (SAX, Stax, dom) this would allow compile time checks if all components have the correct type when assembling the pipeline. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[RT] Using the xml subproject in C3
Hi, I think we should use the new xml subproject (containing sax and dom utility classes) in C3. If noone objects, I could do the changes in the next days. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Avoid escaping chars in script/style only in HTMLSerializer? (Re: svn commit: r515096)
Andreas Hartmann schrieb: Hi Carsten, cziege...@apache.org schrieb: Author: cziegeler Date: Tue Mar 6 04:11:29 2007 New Revision: 515096 URL: http://svn.apache.org/viewvc?view=revrev=515096 Log: Correctly handle content of script and style tag as cdata for html. is there a particular reason why this change hasn't been applied to the XHTMLSerializer as well? IIUC, the script/style CDATA handling is also defined for XHTML [1]. I don't know anymore - we had a discussion about this at that time, and I think the outcome was to only apply it to the html serializer. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [C3] Pipeline component event types
Steven Dolg wrote: Carsten Ziegeler schrieb: Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a stax pipeline, perhaps sharing a common interface? From my point of view: Currently the user must know which components he needs (as in I want to process XML and I'd like to do it with StAX). As soon as he know this, he just selects the components (either existing or created) but them in *any* pipeline (caching/noncaching/etc.) But the user needs to choose the same xml transportation for all components in the pipeline, being it directly or through wrappers. If there were multiple, content-specific Pipelines he still needs to know which components, but also which type of Pipeline. If he feels the need to change to SAX (so a switch in the event type - IMO a sub-optimal term, since not every component actually passes nice events like StAX does) he also needs to change the Pipeline. This may seem easy now, but imagine a larger system. Changing the pipeline type can be challenging there. From what I understand so far in this discussion this simple switching does not work (or is not intended to be implemented - which is fine for me). So besides from switching the pipeline implementation you have to switch all components or at least add matching wrappers around them. And what about automatically generated pipelines (e.g. the sitemap). This will be so much harder as you have to collect and analyze all components first before you can actually build the pipeline to use. I think you have to do this anyway - as not all components fit together. Defining a common interface for different pipeline types does not really change this. If the common interface is sufficient for handling and operating the pipeline they are exchangable (from the callers point of view) and provide the same environment we have now. If the common interface is not sufficient for handling and operating the pipeline it is merely a marker interface and it probably wouldn't make much difference. (Although it is still useful for declaring parameter types, etc.) I may be biased here ;-) but I have yet to see the benefits of different pipeline types... :) I have the same feeling for the opposite...if I can't just mix dom with sax and maybe stax, then why following this generic approach? Hmm, maybe generics could help? So we have something like: public interface PipelineT extends PipelineComponent and have sub interfaces for PipelineComponent for sax, dom, stax? This ensures to have a single implementation but gives compiler time checks. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [C3] Pipeline component event types
Reinhard Pötz wrote: The situation is similar to Spring which allows the wiring of components that don't fit together. As long as I get proper error messages I don't really have a problem with it. Now, I think Spring config can be a nightmare, but that's a different problem :) Yes, proper error messages are a must. Currently we have 3 different pipeline implementations (noncaching, caching, async-caching). Your approach would multiply these three implementations with the content specific implementations that we would have to maintain separately. This doesn't sound like a promising approach. Now, the impl should be shareable, I totally agree that having to maintain 9 (or more) implementations that vary only a little bit is a nightmare. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [C3] Pipeline component event types
Steven Dolg wrote: I don't think I understand what you mean by same xml transportation. Ah sorry, this was a try to find something better than event types. Currently creating and executing a pipeline looks like: Pipeline pipeline = ...; pipeline.add(new StAXGenerator(inputURL)); pipeline.add(new StAXTransformer(myParameter)); pipeline.add(new StAXSerializer(); pipeline.setup(outputStream); pipeline.execute(); It is the same when using SAX (except different components, of course) or when processing any other type of data (I think I should really go and build that Imaging module...). Yes, sure - but: Pipeline pipeline = ...; pipeline.add(new StAXGenerator(inputURL)); pipeline.add(new SAXTransformer(myParameter)); pipeline.add(new StAXSerializer(); wouldn't work - and maybe this wouldn't even end in an exception. The pipeline has no knowledge of the possible event types and which event types are compatible. So how can it check the validity of this pipeline? Again I have the feeling that some concepts that Cocoon has for years now (Pipelines look like Generator - Transformer - Serializer; make sure the sitemap makes sense; know what the components actually do) are all of a sudden too complicated for any user to apply them safely without reading the source code. But that may be just me... Hehe...no, no, it's not about the generator, transformer, serializer and how to chain them. For instance, the old cocoon pipeline interface made sure that you add the components to the pipeline in the correct order (first generator, then transformers, finally serializer). Just because something has been in one way or the other for years, doesn't mean that it's good and can't be made better/easier. :) This simple switching of components works right now! While creating the StAX components we often exchanged the components (again all of them, not individual ones - SAX and StAX are not compatible without adapters) to compare the results from SAX and StAX. Yes, that's my point - you have to change all components in the pipeline. IMO demanding that the user also selects the correct pipeline type for his choice of components - that need to be compatible with each other *and* the pipeline - is actually more than just demanding that he chooses components that are compatible with each other and guaranteeing that any (correctly implemented) pipeline will do the job. Hmm, the user has to select the correct pipeline type, yes, but I don't think that this is more complicated - and it would allow compile time checking of the components. The components need to communicate with each other nonetheless. The additional Are you compatible with me? check is fairly easy compared to that (for StAX that are 3 lines of code in one abstract base class). Hmm, ok. Being able to use the same Pipeline implementations (even the rather sophisticated asynchronous caching pipeline) has saved us probably days of work and that compatibility check took no more than 5 minutes once the interfaces for the components (which we needed anyway) were defined. Yes, but that's you doing the stuff (or other people involved in implementing c3). For new users it is a little bit more complicated. Ok, granted, maybe I'm overestimating the benefit of the compile time check. Don't know. So we have something like: public interface PipelineT extends PipelineComponent and have sub interfaces for PipelineComponent for sax, dom, stax? This ensures to have a single implementation but gives compiler time checks. Well that would be nice of course. But so far not working solution/prototype has been made available (or did I simply miss it?). :) No of course you didn't miss it. Maybe I have time to look into this next week. And those that have merely scratch surface IMO. There are still things like component order: Generator, Generator, Transformer, Serializer, Generator is clearly not a valid pipeline, even if all components are actually using the same technology. Yes, but this can be checked immediately when the component is added to the pipeline. Of course, this is not a compile time check. Maybe we don't need to change this and just properly naming things (like either adding SAX etc. to the class name or as a package) is enough. I actually don't know, but I think the easier we make it and the more we can check at compile time, the more we attract possible users. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [C3] Caching
Reinhard Pötz wrote: I would only make the caching file generator available to the sitemap. If you put it into a caching pipeline, its caching interfaces will be regarded, if it is used in a noncaching pipeline, the CachingPipelineComponent interface will be disregarded. Hmm, yes, sounds much simpler :) I'm not sure if it is a good idea to introduce aspect orientation at this level which adds a further level of complexity. I also fear that this will not be a solution that works for every scenario and if it's only one component that can't be cached transparently by AO mechanisms we get a problem where to put it because we wouldn't want to introduce a dependency on the caching module. Hmm, I don't meant real aop - I haven't looked into the caching pipeline impl, but I guess it checks each component if it implements the caching pipeline component interface. If the component does not implement it, the caching pipeline could try this default behaviour. Without thinking this through, I see two downsides: the cache key might contain stuff which is not required (this should be neglectable). The pipeline ends up to be always cacheable, regardless if the components itself support caching - this might be not the desired effect - I don't know :) If we want to clean up the cocoon-pipeline module, it's probably a better idea to create a 'cocoon-sax' module and we move all SAX related classes there. Then 'cocoon-pipeline' contains the core interfaces and the pipeline implementations (incl. caching). I think we should do both :) Carsten -- Carsten Ziegeler cziege...@apache.org
Re: ApacheCon US
Thorsten Scherler wrote: On Sat, 2008-09-06 at 00:44 +0200, Joerg Heinicke wrote: Hey guys, I'm considering to go to New Orleans. I justed wanted to ask who is planning to go as well and if anybody wants to share a room. I will be there as well, but as well already sharing my room. Same here Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Please, let's not get into the usual maven bashing threads. I'm tired of reading all the love and hate about maven over and over again. If someone thinks that the current system sucks *and* has time to try out new things, great. If not, let's keep the working system. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote: I thought about this some more. How about if a) to enable this feature you put a variable as the version, b) the variable is replaced by its definition c) if it isn't defined then go to the relativePath and get the version from there, c) if this fails throw an exception. I believe this won't cause any problems since variables aren't currently supported. It is also what people have asked for in the Jira issue. Sounds like too much magic for me - but as we're talking about maven, well, adding more magic to too much magic shouldn't hurt... :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote: Carsten Ziegeler wrote: Ralph Goers wrote: It uses the relative path so you will need the parent also. Hmm, I'm not sure if this is a good idea :) as it permits building a module standalone. For Cocoon we have the dream (tm) to have separate buildable/deployable modules one day. Carsten If you can think of a way to have it both ways let me know. You could look into the local repo and use the latest version from there or you can even go to a remote repo and use the latest version from there. I think/hope that the maven api allows you to do this. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [vote] Cocoon 3.0
+1 Carsten Reinhard Pötz wrote: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. This majority vote stays open for 72 hours. Please cast your votes. Here is my +1 -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Reinhard Pötz wrote: yes, I was too lazy to touch nearly every POM file in our repository just to increase the version number of our parent POMs. I haven't done this for the last release either and AFAICT, no problem occurred. Does anybody know if it can cause problems if the development version number isn't increased after a release? I think we shouldn't change the version number just for the sake of changing it. If the pom doesn't change why should we increase the version number? I think we should simply drop the parent relationship from all modules and use the current parent poms just as reactor poms. Every real module pom directly has our root pom as the parent. This makes releasing imho much easier as there is no release of any intermediate pom required anymore. We're using this approach for a very long time now and it has made things much easier. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Reinhard Pötz wrote: I was releasing cocoon-parent because I wanted to use the latest versions of some plugins and some dependencies (e.g. Spring). Ah yes, ok - Personally I would not change the references of all modules to the latest snapshot of the parent pom after a release. The modules should be indepedent. Now comes the problematic part: As soon as you end up with two modules referencing different parent pom with a dependency management, and let's say the older parent pom references a lib or plugin in version X while the newer parent pom references the same lib or plugin in a different version Y, all modules are build with one or the other version in a multi project build. Which version is used for the whole build depends on the order how maven reads the poms (and it seems that this order is not deterministic as we had problems on some machines while it worked on others because of a different order). And obviously if just one version is used for the whole build this might cause build problems - which look very strange as all your poms are correct! Ok, long story, because of this maven bug (or is it by design?) it's much safer to make a search/replace after releasing the parent pom and update *all* modules to the new trunk version. Or, which is the slightly better but more difficult option, do this after you apply the first change to the parent pom after a release. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote I'm actually working on a fix to maven for this at the moment. It would allow you to put versionMAVEN_PARENT_VERSION/version in the pom instead of an actual version number. Don't get your hopes up though. I've been working on this for the last few weeks in the precious little available time I have right now. The thing that makes it difficult is that when your pom gets installed or deployed it has to have a real version number in it. And how does this work, if you just check out a single module instead of the whole tree? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
Reinhard Pötz wrote: You guys have finally convinced me. Let's use 3.0.x for Corona, clearly state that it is alpha software on the website in the README.txt of each release artifact and see what's happening. Then we only need to find a package name that isn't used in trunk because Corona should run in parallel with Cocoon 2.2 without a problem (haven't tried it yet but at least in theory). The simplest solution would be keeping 'corona' as part of the package name (org.apache.cocoon.corona). IIRC Tomcat also kept the 'catalina' package names. Any other suggestions? I forgot to mention that we also have to find unique Maven artifact IDs for the reasons explained above. Great, I'm fine with using 3.0.x as well. For the package names and artifact ids, I'm not sure if we should keep corona inside. I would prefer to simply use different functional package names. And if we use the package names as group ids, we're fine. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: svn commit: r682461 [1/2] - in /cocoon/trunk/blocks/cocoon-portal: cocoon-portal-api/ cocoon-portal-api/src/main/java/org/apache/cocoon/portal/ cocoon-portal-api/src/main/java/org/apache/cocoon/po
Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: cziegeler Date: Mon Aug 4 11:49:15 2008 New Revision: 682461 URL: http://svn.apache.org/viewvc?rev=682461view=rev Log: Move api from impl to api. Sorry for this - damn Eclipse is not telling you when a commit is failing. It pretends it worked :( Fortunately this bug is fixed since today...as well as Cocoon trunk Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: A new name for Corona (take 2)
Reinhard Pötz wrote: I still think that we shouldn't use a descriptive name in order to not confuse our users (and ourselves). The more I think about it, the more I come to the conclusion that we should use descriptive names :) The current Corona code is a collection of various modules that are developed in layers. I can use the lowest layer (the pipelines) without ever using the above layers (sitemap, controller etc.). So I end up with using a part of Corona. This part is (small) project on its own and imho calls for an own name. If we think further ahead, we might come to the point where we base Cocoon 3.0 on Corona - and I think at this point, it's easier if we have descriptive names - as a Cocoon 3.0 is just the assembly of the separate parts with some additional sugar on top (ok, this might sound easier as it might be in the end, but anyway). If you look at other projects, for instance Spring or Felix, they're doing it the same way: descriptive names. Atm we have only a small set of modules in the Corona code, but perhaps this might crow and the more it crows, the more difficult it will be to tell people what Corona is. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
