]? 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
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
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
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
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
[
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
[
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
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
Anyone else? We need two more binding votes.
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-xml/2.0.2/
Please cast your votes.
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
+1
Regards
Carsten
--
Carsten Ziegeler
cziege...@apache.org
[
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
[
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
[
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
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
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
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
Carsten
--
Carsten Ziegeler
cziege...@apache.org
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
+1
Carsten
--
Carsten Ziegeler
cziege...@apache.org
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
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
/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
) 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
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
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
--
Carsten Ziegeler
cziege...@apache.org
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
/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
[
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
[
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
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
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
Hi,
I'll drop my suggestions and close the bug.
Thanks for the feedback
Carsten
--
Carsten Ziegeler
cziege...@apache.org
[
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
[
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
it would be great if others could voice their opinion.
Thanks
Carsten
--
Carsten Ziegeler
cziege...@apache.org
[
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
--
Carsten Ziegeler
cziege...@apache.org
to explain the difference between the existing abstract
classes/interfaces :)
HTH
Carsten
--
Carsten Ziegeler
cziege...@apache.org
[
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
, 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
to just download the configurator, but I still can't see
the docs :)
Carsten
--
Carsten Ziegeler
cziege...@apache.org
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
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
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
/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
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
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
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
into account;
binding votes are votes from the PMC members.
HTH
Carsten
--
Carsten Ziegeler
cziege...@apache.org
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
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
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
+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
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
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
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
/cocoon-xml/2.0.0/
Please cast your votes.
Carsten
--
Carsten Ziegeler
cziege...@apache.org
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
[
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
/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
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
that means in the end).
Carsten
--
Carsten Ziegeler
cziege...@apache.org
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
.
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
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
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
change everything - but I don't think that this is required :)
Carsten
--
Carsten Ziegeler
cziege...@apache.org
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
enough time
to finish it, I'd like to add it to the cocoon-rest module.
Comments?
+1
Carsten
--
Carsten Ziegeler
cziege...@apache.org
-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
[
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
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
[
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
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
: 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
[
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
[
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
[
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
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
[
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
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
--
Carsten Ziegeler
cziege...@apache.org
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
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
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
implementations (incl. caching).
I think we should do both :)
Carsten
--
Carsten Ziegeler
cziege...@apache.org
here
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
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
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
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
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
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]
--
Carsten Ziegeler
[EMAIL PROTECTED]
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]
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
. And if we use the package names as group ids, we're fine.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
. It pretends it worked :(
Fortunately this bug is fixed since today...as well as Cocoon trunk
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
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
1 - 100 of 3237 matches
Mail list logo
