Re: [2.1.10] WildcardHelperTestCase fails
Afaik, the code for the wildcard helper has been replaced after that by
someone else.
Carsten
Bertrand Delacretaz wrote:
Just tried to run the junit tests on BRANCH_2_1_X, and the second
assertion in WildcardHelperTestCase fails:
public void testEndPattern() throws Exception {
final Map resultMap = new HashMap();
final String pattern = */;
final int[] expr = WildcardHelper.compilePattern(pattern);
boolean result = WildcardHelper.match(resultMap, foo/bar/, expr);
// this one passes
assertFalse(Url 'foo/bar/' should not match pattern '*/'., result);
// this one fails
result = WildcardHelper.match(resultMap, test/foo/bar/, expr);
assertFalse(Url 'test/foo/bar/' should not match pattern
'*/'., result);
result = WildcardHelper.match(resultMap, foo/, expr);
assertTrue(Url 'foo/' should match pattern '*/', result);
IIUC, this is related to http://tinyurl.com/ydvkcb , but Carsten says
in that thread that the bug has been fixed. Any clues?
(environment: macosx 10.4.8, JDK 1.5.0_06)
-Bertrand
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
RE: i18nTransformer problems with static pages
You should add an extra stylesheet that removes superfluous namespace
attributes. This is what I've done:
I used to use this strategy as well, though recently I replaced this xsl
transformer with a custom StripNameSpacesTransformer (about just 10 lines),
which outperforms the slow xsl transformation a factor 30 for small xml docs,
over hundreds of times for bigger xml docs. I am not sure if it is already
available in cocoon in some transformer.
If somebody is interested in the code, I can attach it,
Regards Ard
xsl:template match=*
!-- remove element prefix (if any) --
xsl:element name={local-name()}
!-- process attributes --
xsl:for-each select=@*
!-- remove attribute prefix (if any) --
xsl:attribute name={local-name()}
xsl:value-of select=./
/xsl:attribute
/xsl:for-each
xsl:apply-templates/
/xsl:element
/xsl:template
Add a generic catchall template or you end up with nothing:
!-- = --
!-- generic catchall template --
!-- = --
xsl:template match=text()
xsl:copy
xsl:apply-templates select=text()/
/xsl:copy
/xsl:template
HTH
Bye, Helma
Re: i18nTransformer problems with static pages
Ard Schrijvers wrote:
You should add an extra stylesheet that removes superfluous namespace
attributes. This is what I've done:
I used to use this strategy as well, though recently I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30 for small xml docs, over hundreds of times for bigger xml docs. I am not sure if it is already available in cocoon in some transformer.
If somebody is interested in the code, I can attach it,
if you mean adding to trunk/branch21, +1
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: i18nTransformer problems with static pages
On 12/5/06, Ard Schrijvers [EMAIL PROTECTED] wrote: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! -Bertrand
RE: i18nTransformer problems with static pages
...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) Will add it to trunk/branch Ard -Bertrand
Re: i18nTransformer problems with static pages
Ard Schrijvers said the following on 5/12/06 12:40: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) Will add it to trunk/branch As a friend of mine says: it's always amazing to see how easy it is to make Cocoon do very difficult things when it is so hard to make it do the trivial things, so by all means submit your transformer and I'm your first customer. ;-) Bye, Helma
[SURVEY] cocoon eventcache block
Hello, I am wondering if there is anybody using the cocoon eventcache block (without using hippo jars), or are planning to do so in the future? Regards Ard -- Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / http://www.hippo.nl --
Re: [SURVEY] cocoon eventcache block
Ard Schrijvers wrote:
Hello,
I am wondering if there is anybody using the cocoon eventcache block (without using hippo jars), or are planning to do so in the future?
I'm working on a cocoon-daisy block which will make use of the EventCache too.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Building changes into the top level sitemap
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. Read the Maven Manuals as you've read the Ant one years ago :-) Ciao - -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdXc/LNdJvZjjVZARAmJlAJoCunJ9CFm17/S+04n7/Bc3f0GVIwCeIUh6 DsTMtr3sN+t4/cJf6MFaOps= =Y0ix -END PGP SIGNATURE-
Re: Building changes into the top level sitemap
Jeremy Quinn wrote:
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like (and
adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap
uri-prefix=_cocoon/system//
/map:when
map:otherwise
map:mount
src=resource://org/apache/cocoon/{1}/system/sitemap.xmap
uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to the
samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know where
to start solving this.
What am I supposed to do ?
Thanks for any suggestions
One of our problems is that we use the styling resources from cocoon-webapp. We
have to move all styling related things into cocoon-samples-style-default and
use it from all our sample blocks instead of using the infamous context protocol.
For system resources we should provide a system-resources block. For now it
could be mounted at _cocoon, later we should install a
LinkRewritingTransformer that is aware of blocks.
One problem with these changes is, that they are incomptable with 2.1. As we are
sharing them across both versions. For this reason I propose to create a
cocoon-forms-samples-22 block that makes use of blocks and we have the
opportunity to tidy up a bit.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Building changes into the top level sitemap
Jeremy Quinn skrev:
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap
uri-prefix=_cocoon/system//
/map:when
map:otherwise
map:mount
src=resource://org/apache/cocoon/{1}/system/sitemap.xmap
uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Yes, that should be the place.
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to the
samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know where
to start solving this.
What am I supposed to do ?
First, the dist samples (cocoon-dist-samples, cocoon-dist-publishing)
are really just distribution samples. They just unpack and package
together the cocoon-webapp and samples and implementations from the
various blocks. For development of samples it would be really
inconvenient to work from the dist samples as you would need to rebuild
about the whole trunk after each change.
So what I would recommend to do is to start from the cocoon-webapp
instead and to add (locally) all the block samples you need for your
work, as dependencies to cocoon-webapp. What happens then is that during
startup Cocoon will find all the COB-INF directories from the block
samples from the class path. From here two different things can happen:
if the block is in a jar at the class path, the COB-INF directory of the
block will be unpacked in a blocks/blockname directory in the temp
directory of the servlet container. If the block is in a class directory
(if you devolop in Eclipse e.g. and your cocoon-webapp depends on
another block project), Cocoon will read directly from the block without
any unpacking.
All this is done by using a new blockcontext protocol that is aware of
the locations of the blocks (see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116326232408386w=2).
So the above should hopefully make it easier to work on making the new
stuff functional. After that you can try to compile the dist samples and
see if it works in them as well.
The above described functionality actually make it easier and faster
than ever to develop samples, as you can test them without any copying
or jetty restarts at all in Eclipse. But some documentation about this
would probably not hurt ;)
/Daniel
Updating POM versions throughout our codebase
I forgot one thing to ask: Do we already have a script that updates all
dependencies of a library/module to a new version? Without it, it isn't really
fun to do a release. If not, help is more than appreciated!
(I can't do the release today as I don't have enough time. I will let you know
as soon as I have time, if nobody is faster than me!)
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: i18nTransformer problems with static pages
On 12/5/06, Ard Schrijvers [EMAIL PROTECTED] wrote: You should add an extra stylesheet that removes superfluous namespace attributes. This is what I've done: I used to use this strategy as well, though recently I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30 for small xml docs, over hundreds of times for bigger xml docs. I am not sure if it is already available in cocoon in some transformer. If somebody is interested in the code, I can attach it, Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? -- Peter Hunsberger
Re: [RT] Improved matching selecting
Hi Alfred, On Dec 4, 2006, at 12:46 PM, Alfred Nathaniel wrote: Or use different tags, say in resemblance to XSLT: map:if path=... ... /map:if map:choose map:when path=... I'm not so keen on that, 'cause I'm actually trying to get away from using 2 different elements for this. Rationale: 1) The precedent of match and select would have conditioned users to interpret if and choose as referring to two different kinds of sitemap components (Iffers and Choosers? :-). I'd like the syntax to emphasize that it's all matching and there is only one component now, The Matcher. 2) The sitemap language is not XSLT and has nothing to do with XSLT. The only relationship is that the sitemap has to do with Cocoon and Cocoon uses XSLT... big deal! :-) Trying to imitate XSLT in the sitemap in the interest of familiarity IMHO is misguided and results in confusion. Things that are different should look and feel different. For example: in XSLT if and choose, the @test clause contains a predicate. This is fundamentally different then in the sitemap, where the corresponding attribute contains a pattern, and the predicate comprises some kind of (implicit or configured) match of this pattern against a configured target value. Now the way this is expressed in the classic sitemap, the select/when version puts this value into an attribute called test — probably, again, in deference to XSLT, and IMHO confusing — while the match version puts it in an attribute called pattern. But in either case, the semantics are rather different than XSLT owing to the difference between predicate and pattern. 3) I think XSLT got it wrong :-). They should have used something like xsl:cond for both, and treated @test like I treat @value in my proposal. An analogy between xsl:choose and a switch or case statement is flawed, the correct analogy is to if()... else if() — again, because of the distinction between predicate and pattern! Switch/case is really like today's map:select!!! if()... inaugurates a conditional using the same keyword regardless of how many alternatives there are — one, or many. That's how sitemap matching (which has only patterns) should do it, and that's how XSLT (which has only predicates) should have done it. No need for two different keywords. cheers and thx for the feedback :-), —ml—
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 7:35 AM, Peter Hunsberger wrote: Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? +1 IIRC this very thing was proposed some time ago and either rejected for some reason, or just didn't happen. I think it's a great idea, but it'd be worth a troll through the archives to see if there isn't some compelling reason not to. —ml—
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. OK, Thanks, I am trying that now . Getting NPEs from org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) now while trying to run $ mvn install or $ mvn package in dists/cocoon-dist-samples/ Trying a complete clean install from scratch. (Why does this happen in such an unpredictable way ?) core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. Read the Maven Manuals as you've read the Ant one years ago :-) Excuse the mild sarcasm, but I never actually had to read the Ant manual to develop for Cocoon 2.1 :-) Thanks for your reply regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:49, Reinhard Poetz wrote:
Jeremy Quinn wrote:
Hi Guys
I am trying to get support for the new Upload Progress Bar working
in Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available
for the 'cocoon-dist-samples' and everything else that may be
built from this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
One of our problems is that we use the styling resources from
cocoon-webapp. We have to move all styling related things into
cocoon-samples-style-default and use it from all our sample blocks
instead of using the infamous context protocol.
For system resources we should provide a system-resources block.
For now it could be mounted at _cocoon, later we should install a
LinkRewritingTransformer that is aware of blocks.
The idea was that any block could provide a system pipeline. In this
case, the system pipeline is provided by the Ajax Block.
One problem with these changes is, that they are incomptable with
2.1. As we are sharing them across both versions. For this reason I
propose to create a cocoon-forms-samples-22 block that makes use of
blocks and we have the opportunity to tidy up a bit.
AFAICS this is the one and only change required to support Upload
Progress that is not shared by Trunk and Branch.
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
Jeremy Quinn wrote:
On 5 Dec 2006, at 13:49, Reinhard Poetz wrote:
For system resources we should provide a system-resources block. For
now it could be mounted at _cocoon, later we should install a
LinkRewritingTransformer that is aware of blocks.
The idea was that any block could provide a system pipeline. In this
case, the system pipeline is provided by the Ajax Block.
This shouldn't be a problem because from the Java level POV there is no
concept of blocks.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: i18nTransformer problems with static pages
Peter Hunsberger wrote: Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. - Obviously not for the XML output (note that xhtml and xml serializer are the same class) Simone
Re: i18nTransformer problems with static pages
On 12/5/06, Simone Gianni [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: Instead of requiring that an extra transformer be added to the pipeline would it make sense to add this capability as a configuration option on the HTML/XHTML serializers? Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. Umm, that's why it would be an _option_... (obviously not the default). - Obviously not for the XML output (note that xhtml and xml serializer are the same class) -- Peter Hunsberger
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 8:38 AM, Simone Gianni wrote: Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. - Obviously not for the XML output (note that xhtml and xml serializer are the same class) Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... —ml—
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 14:04, Daniel Fagerstrom wrote:
Jeremy Quinn skrev:
Hi Guys
I am trying to get support for the new Upload Progress Bar working
in Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Yes, that should be the place.
Good :)
Next I am trying to get this compiled in, so that it is available
for the 'cocoon-dist-samples' and everything else that may be
built from this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
First, the dist samples (cocoon-dist-samples, cocoon-dist-
publishing) are really just distribution samples. They just unpack
and package together the cocoon-webapp and samples and
implementations from the various blocks. For development of samples
it would be really inconvenient to work from the dist samples as
you would need to rebuild about the whole trunk after each change.
OK
So what I would recommend to do is to start from the cocoon-webapp
instead and to add (locally) all the block samples you need for
your work, as dependencies to cocoon-webapp. What happens then is
that during startup Cocoon will find all the COB-INF directories
from the block samples from the class path. From here two different
things can happen: if the block is in a jar at the class path, the
COB-INF directory of the block will be unpacked in a blocks/
blockname directory in the temp directory of the servlet
container. If the block is in a class directory (if you devolop in
Eclipse e.g. and your cocoon-webapp depends on another block
project), Cocoon will read directly from the block without any
unpacking.
All this is done by using a new blockcontext protocol that is aware
of the locations of the blocks (see http://marc.theaimsgroup.com/?
l=xml-cocoon-devm=116326232408386w=2).
So the above should hopefully make it easier to work on making the
new stuff functional. After that you can try to compile the dist
samples and see if it works in them as well.
The above described functionality actually make it easier and
faster than ever to develop samples, as you can test them without
any copying or jetty restarts at all in Eclipse. But some
documentation about this would probably not hurt ;)
Documentation would really help.
I have just been working on an established project that is built from
2.2 and I could see the advantages of the new platform.
However, many perceive 2.2 as almost unusable. It clearly is being
used but the procedures are very different from 2.1 . the results
can be completely unpredictable . it will compile one minute and
not the next, this is very off-putting. If the less experienced
developers like myself cannot feel confidant with the build system
for 2.2 what hope do we have of users embracing it?
Sorry this is in no way intended as a personal criticism, merely a
statement of facts as I perceive them.
From my PoV, the areas most urgently in need of documentation are :
A cookbook for how to develop 2.2 (as you describe)
Recipes for starting your own project.
Troubleshooting hint for solving common build problems.
Reading the Maven2 manual as Giacomo suggested, may well help :) but
that still leaves understanding how 2.2 performs it's built using Maven.
Thanks for your reply :)
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 16:25, Reinhard Poetz wrote: Jeremy Quinn wrote: On 5 Dec 2006, at 13:49, Reinhard Poetz wrote: For system resources we should provide a system-resources block. For now it could be mounted at _cocoon, later we should install a LinkRewritingTransformer that is aware of blocks. The idea was that any block could provide a system pipeline. In this case, the system pipeline is provided by the Ajax Block. This shouldn't be a problem because from the Java level POV there is no concept of blocks. Good, that is what I thought. Thanks. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: i18nTransformer problems with static pages
On 12/5/06, Mark Lundquist [EMAIL PROTECTED] wrote: On Dec 5, 2006, at 8:38 AM, Simone Gianni wrote: Care is required : some emerging internet standards (XForms for example, but also others) do require namespaces, so : - Okay for the HTML serializer - Not okay for the Xhtml serializer, in this case eventually provide a list of namespaces to remove, and by default fill this list with namespaces from cocoon. - Obviously not for the XML output (note that xhtml and xml serializer are the same class) Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... I could see both options. There are some cases where I really don't need any namespaced elements at all on my output (eg, stuff I'm manipulating for AJAX code). We strip them out with XSLT at the moment, but... -- Peter Hunsberger
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. Ever since I ran $ mvn install in core/cocoon-webapp/, I cannot get $ mvn package to work in dists/cocoon-dist-samples/. No matter how many times I run it (I also went back and did a complete clean install from root) I get this from the build : [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) at org.apache.maven.plugin.war.AbstractWarMojo.unpackWarToTempDirectory (AbstractWarMojo.java:680) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp (AbstractWarMojo.java:600) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp (AbstractWarMojo.java:379) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCoco onAppAsWebapp(AbstractDeployMojo.java:182) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute (DeployExplodedMojo.java:64) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) And of course I don't have a clue where to start looking . regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: i18nTransformer problems with static pages
Mark Lundquist wrote: Is there ever a need to retain namespace declarations for namespaces that are not actually used in the result document, i.e. for which there is no element with that namespace? I think the idea is to just delete extraneous namespace declarations, not to delete them all... Yep, the problem with this approach is that you manage to know if a namespace declaration has been used only when you reach the end of the document (after checking that no element used it), while the declaration is quite commonly on the root element. Buffering all the SAX event for each html page served by cocoon would be a problem :) What i was proposing would be simply to enable it by default (already too many options in cocoon, and if a page containing a i18n namespace declaration is not visualized by IE, by default cocoon should not send it), but limit it's influence on a set of namespaces (all namespaces http://cocoon.apache.org for example) and eventually have this set configurable by the user so that there will be no need in the future for remove-that-certain-unwanted-ns.xsl files :D Simone
[jira] Created: (COCOON-1963) Add a redirect action to the browser update handler
Add a redirect action to the browser update handler
---
Key: COCOON-1963
URL: http://issues.apache.org/jira/browse/COCOON-1963
Project: Cocoon
Issue Type: New Feature
Components: Blocks: Ajax
Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Reporter: Alexander Klimetschek
In some situations you want to redirect the browser to a different page inside
a cforms action, eg. you have a REST-style interface and create something under
the URL /new (which shows a form to enter your new data) and on save you want
to redirect the user to a page where that new data is stored (e.g. /foobar42).
To do so in an ajax-environment, where the save action will be answered with a
browser-update XML snippet, you need a separate action in the browser update
handler. This patch adds the handling of a simple redirect action to the
BUHandler.js:
bu:document
bu:redirect uri=foobar42 /
/bu:document
If you want to have a fallback solution for non-AJAX cases, you need to trigger
a normal HTTP redirect from your pipeline. This must happen when this
bu:redirect is inside the XML stream, otherwise all content should be
serialized to the browser. That functionality is provided by the attached
RedirectTransformer. The usage would be like:
select type=ajax-request
when test=false
transform type=redirect /
/when
/select
The server-side javascript snippet for the save action should look like (form
is the Form object and documentID=foobar42):
if (newDocument) {
form.getWidget().endProcessing(false);
cocoon.redirectTo(cocoon:/redirectTo/ + documentID);
}
There should be a pipeline that matches /redirectTo/* and that serves the
bu:document like above (eg. via a jx template to insert the documentID).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1963) Add a redirect action to the browser update handler
[ http://issues.apache.org/jira/browse/COCOON-1963?page=all ]
Alexander Klimetschek updated COCOON-1963:
--
Attachment: BUHandler.js
Not a patch, but the entire new version of BUHandler.js (sorry, but I currently
don't have the environment to test it out directly in cocoon-ajax)
Add a redirect action to the browser update handler
---
Key: COCOON-1963
URL: http://issues.apache.org/jira/browse/COCOON-1963
Project: Cocoon
Issue Type: New Feature
Components: Blocks: Ajax
Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Reporter: Alexander Klimetschek
Attachments: BUHandler.js
In some situations you want to redirect the browser to a different page
inside a cforms action, eg. you have a REST-style interface and create
something under the URL /new (which shows a form to enter your new data) and
on save you want to redirect the user to a page where that new data is stored
(e.g. /foobar42). To do so in an ajax-environment, where the save action will
be answered with a browser-update XML snippet, you need a separate action in
the browser update handler. This patch adds the handling of a simple
redirect action to the BUHandler.js:
bu:document
bu:redirect uri=foobar42 /
/bu:document
If you want to have a fallback solution for non-AJAX cases, you need to
trigger a normal HTTP redirect from your pipeline. This must happen when this
bu:redirect is inside the XML stream, otherwise all content should be
serialized to the browser. That functionality is provided by the attached
RedirectTransformer. The usage would be like:
select type=ajax-request
when test=false
transform type=redirect /
/when
/select
The server-side javascript snippet for the save action should look like (form
is the Form object and documentID=foobar42):
if (newDocument) {
form.getWidget().endProcessing(false);
cocoon.redirectTo(cocoon:/redirectTo/ + documentID);
}
There should be a pipeline that matches /redirectTo/* and that serves the
bu:document like above (eg. via a jx template to insert the documentID).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1963) Add a redirect action to the browser update handler
[ http://issues.apache.org/jira/browse/COCOON-1963?page=all ]
Alexander Klimetschek updated COCOON-1963:
--
Attachment: RedirectTransformer.java
The RedirectTransformer with a different package name. Should IMHO go into
cocoon ajax, just next to the BrowserUpdateTransformer.
Add a redirect action to the browser update handler
---
Key: COCOON-1963
URL: http://issues.apache.org/jira/browse/COCOON-1963
Project: Cocoon
Issue Type: New Feature
Components: Blocks: Ajax
Affects Versions: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Reporter: Alexander Klimetschek
Attachments: BUHandler.js, RedirectTransformer.java
In some situations you want to redirect the browser to a different page
inside a cforms action, eg. you have a REST-style interface and create
something under the URL /new (which shows a form to enter your new data) and
on save you want to redirect the user to a page where that new data is stored
(e.g. /foobar42). To do so in an ajax-environment, where the save action will
be answered with a browser-update XML snippet, you need a separate action in
the browser update handler. This patch adds the handling of a simple
redirect action to the BUHandler.js:
bu:document
bu:redirect uri=foobar42 /
/bu:document
If you want to have a fallback solution for non-AJAX cases, you need to
trigger a normal HTTP redirect from your pipeline. This must happen when this
bu:redirect is inside the XML stream, otherwise all content should be
serialized to the browser. That functionality is provided by the attached
RedirectTransformer. The usage would be like:
select type=ajax-request
when test=false
transform type=redirect /
/when
/select
The server-side javascript snippet for the save action should look like (form
is the Form object and documentID=foobar42):
if (newDocument) {
form.getWidget().endProcessing(false);
cocoon.redirectTo(cocoon:/redirectTo/ + documentID);
}
There should be a pipeline that matches /redirectTo/* and that serves the
bu:document like above (eg. via a jx template to insert the documentID).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Building changes into the top level sitemap
OK, so even though I could not get $ mvn package to run inside the dists/cocoon-dist-samples, I found that the changes to the top-level sitemap from core/cocoon-webapp/ had in fact been added to the sitemap at : dists/cocoon-dist-samples/target/cocoon-samples/ sitemap.xmap I was able to start Jetty in : dists/cocoon-dist-samples When I went to http://localhost:/_cocoon/system/ajax/upload/ status I get this error : java.io.FileNotFoundException: Could not open ServletContext resource [/resource://org/apache/cocoon/ajax/system/sitemap.xmap] Why should it say /resource:// ? (the leading slash is not in the sitemap.) Doing a $ jar -tf dists/cocoon-dist-samples/target/cocoon-samples/WEB- INF/lib/cocoon-ajax-impl-1.0.0-M2-SNAPSHOT.jar I see all of the new stuff that is needed : . . . org/apache/cocoon/ajax/system/i18n/messages.xml org/apache/cocoon/ajax/system/sitemap.xmap org/apache/cocoon/ajax/system/System.JSON.js org/apache/cocoon/ajax/system/System.Upload.js . . . Am I looking in the right place? Thanks regards Jeremy On 5 Dec 2006, at 17:08, Jeremy Quinn wrote: On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. Ever since I ran $ mvn install in core/cocoon-webapp/, I cannot get $ mvn package to work in dists/cocoon-dist-samples/. No matter how many times I run it (I also went back and did a complete clean install from root) I get this from the build : smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 17:38, Jeremy Quinn wrote: Am I looking in the right place? OK, so as Jetty starts up, it reports that it loads ~/.m2/repository/ org/apache/cocoon/cocoon-ajax-impl/1.0.0-M2-SNAPSHOT/cocoon-ajax- impl-1.0.0-M2-SNAPSHOT.jar. I can confirm that the system resources I seek exist there too. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
[jira] Created: (COCOON-1964) Redirects inside a block called via the blocks protocol fail
Redirects inside a block called via the blocks protocol fail
Key: COCOON-1964
URL: http://issues.apache.org/jira/browse/COCOON-1964
Project: Cocoon
Issue Type: Bug
Components: - Blocks Framework
Affects Versions: 2.2-dev (Current SVN)
Reporter: Alexander Klimetschek
If you do a redirect (from within a piece of flowscript
cocoon.redirectTo('cocoon:/foobar') or via redirect-to in the sitemap) inside
a block that was called via the block: protocol will fail since the re-use of
the outputstream of the response (which happens to be a
BlockCallHttpServletResponse) does not work.
This is due to the use of getWriter() after getOutputStream() has already been
called. The servlet api says that only one of them should be called, so there
is a check in the implementation of getWriter() that will throw an
IllegalStateException. The patch removes that check, which is kinda hack, but I
don't know of any other cases within cocoon where such a re-use is made.
The problem could be avoided if during the redirect a reset() or resetBuffer()
would be called on the response, but for some reason this does not happen with
a redirect from within a flowscript for a form.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1964) Redirects inside a block called via the blocks protocol fail
[ http://issues.apache.org/jira/browse/COCOON-1964?page=all ]
Alexander Klimetschek updated COCOON-1964:
--
Attachment: cocoon-allow-redirect-in-called-block.patch
Affects only the cocoon-blocks-fw-impl module.
Redirects inside a block called via the blocks protocol fail
Key: COCOON-1964
URL: http://issues.apache.org/jira/browse/COCOON-1964
Project: Cocoon
Issue Type: Bug
Components: - Blocks Framework
Affects Versions: 2.2-dev (Current SVN)
Reporter: Alexander Klimetschek
Attachments: cocoon-allow-redirect-in-called-block.patch
If you do a redirect (from within a piece of flowscript
cocoon.redirectTo('cocoon:/foobar') or via redirect-to in the sitemap)
inside a block that was called via the block: protocol will fail since the
re-use of the outputstream of the response (which happens to be a
BlockCallHttpServletResponse) does not work.
This is due to the use of getWriter() after getOutputStream() has already
been called. The servlet api says that only one of them should be called, so
there is a check in the implementation of getWriter() that will throw an
IllegalStateException. The patch removes that check, which is kinda hack, but
I don't know of any other cases within cocoon where such a re-use is made.
The problem could be avoided if during the redirect a reset() or
resetBuffer() would be called on the response, but for some reason this does
not happen with a redirect from within a flowscript for a form.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: i18nTransformer problems with static pages
On Dec 5, 2006, at 9:29 AM, Simone Gianni wrote: Yep, the problem with this approach is that you manage to know if a namespace declaration has been used only when you reach the end of the document (after checking that no element used it) Yeah, it takes two passes. Better to declare up-front which namespaces to preserve... What i was proposing would be simply to enable it by default (already too many options in cocoon, and if a page containing a i18n namespace declaration is not visualized by IE, by default cocoon should not send it), but limit it's influence on a set of namespaces (all namespaces http://cocoon.apache.org for example) and eventually have this set configurable by the user so that there will be no need in the future for remove-that-certain-unwanted-ns.xsl files :D I'm not keen on magic or specialness based on either (a) IE misbehavior, or (b) cocoon URIs. Anyway, like you have said, this thing is starting to have too many options for common feature of XML/HTML serializers... I'm now leaning back toward the idea of a transformer. The objection that it's onerous to include this transformer in every pipeline is weak, because (a) it doesn't have to be in every pipeline, only in final presentation pipelines, and (b) you'd naturally factor that and the serializer into a map:resource anyway. How about a NamspaceTransformer, configured with namespaces null-namespace/ namespace prefix=prefixURI/namespace . . . namespaces Where: 1) If null-namespace is present, then the null NS is the default NS 2) Otherwise, the NS with @default=true is the default NS (more than 1 such = error, or 0 if we have null-namespace/ 3) @prefix is optional; if not set, then use the first prefix found for the NS 4) The transformer writes all the namespace declarations into the root element, deletes them from any descendant elements 5) If a namespace is found that is not in the configured namespaces, throw an error How does that sound? —ml—
Re: [SURVEY] cocoon eventcache block
Ard Schrijvers wrote: Hello, I am wondering if there is anybody using the cocoon eventcache block (without using hippo jars), or are planning to do so in the future? Not using over here. However I was thinking of doing some work on reducing coupling between eventcache and other blocks. Vadim
Re: svn commit: r482168 - in /cocoon/branches/BRANCH_2_1_X: legal/ lib/optional/
Hi, On 4 Dec 2006, at 08:27, [EMAIL PROTECTED] wrote: Author: cziegeler Date: Mon Dec 4 05:27:17 2006 New Revision: 482168 URL: http://svn.apache.org/viewvc?view=revrev=482168 Log: Update to released version of jackrabbit Just curious - Jackrabbit released 1.1.1 yesterday, did you mean to add that rather than 1.0.1? cocoon/branches/BRANCH_2_1_X/lib/optional/jackrabbit- core-1.0.1.jar (with props) Thanks, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Sourcesense: http://www.sourcesense.com/
Re: i18nTransformer problems with static pages
Ard Schrijvers wrote: ...I replaced this xsl transformer with a custom StripNameSpacesTransformer (about just 10 lines), which outperforms the slow xsl transformation a factor 30... This would be useful to have in Cocoon, go for it! I thought it was too trivial :-) There is also less trivial CleanupTransformer [1]. It is overkill though for simple namespace stripping. Vadim [1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/CleanupTransformer.html
Re: i18nTransformer problems with static pages
Sorry Piotr, which version of IE are you using? I can see pages containing xmlns declarations with all IE versions I have here in my office. Quite commonly the blank page in IE is caused by a head like this : html head title/ /head IE is intelligent enought to think that the full page is a title. This happens at least in versions 5.x of IE, and generating such a head is pretty simple : xsl:template head titlexsl:value-of select=somtingwrOnghere//title /head Are you sure the problem is the attribute? Cause if not we are talking about a nice feature but absolutely non blocking and by far not a priority. Simone falcorn wrote: I removed dtd declaration and xml:space attribute has gone; But there is declaration of xmlns:i18n at html tag. And IE dosen't like this attribute. I get blank page. In FF everything is correct, I only get some warrnings from Tidy that there is not standard attribute at html tag: xmlns:i18n greetings Piotr Idzikowski
Re: Building changes into the top level sitemap
On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it is nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? My point would be, don't assume that nearly unusable implies a great gap to be crossed to reach fully usable. My impression is that trunk isn't pervasively unstable, it's just unstable at a few key points, and those are being ironed out by the people who also know how to work around, etc. and also how to just plain use the frigging thing without any documention. So trunk right now is like riding a wild bear, and there's only a few people who know how to ride the bear. Two things to do: (1) tame the bear, and (2) teach ordinary people how to ride a tame bear! This is my observation as a relative outsider, i.e. non-wild-bear-rider. My impression is that (1) is very close. I'm trying to learn now (even though the bear is still a little bit wild), so that I can help with (2). —ml—
Re: Updating POM versions throughout our codebase
2006/12/5, Reinhard Poetz [EMAIL PROTECTED]: I forgot one thing to ask: Do we already have a script that updates all dependencies of a library/module to a new version? Without it, it isn't really fun to do a release. If not, help is more than appreciated! See https://issues.apache.org/jira/browse/COCOON-1890. If you need some help just ask ... (I can't do the release today as I don't have enough time. I will let you know as soon as I have time, if nobody is faster than me!) -- Reinhard Pötz Independent Consultant, Trainer (IT)-Coach -- Andreas
Re: Releasing 2.1.10
hepabolu wrote: If there are no outstanding issues I will assemble a release next monday (11th), put it up for downloading and testing and if nothing bad happens do the release of that assembled version on monday, 18th. +0, won't be able to help though +1 , I can't be of much help either though sorry.. Jorg
[FYI] m2-ibiblio-rsync-repository sync times
(forwarded from repository@) it starts every four hours, starting at 0 CST On 12/5/06, Jorg Heymans [EMAIL PROTECTED] wrote: I don't know if this came up before, but is it documented somewhere at which times this automatic sync occurs? It would help projects to avoid releasing during a sync. Jorg Reinhard Poetz wrote: As you can see from the message below, m2-ibiblio-rsync-repository is automatically synchronized with the central Maven repository. No need for sync requests on repository@apache.org anymore. (This makes a staging repository even more necessary and useful.) Subject: Re: Sync Request: Apache MINA 1.0.1 From: Carlos Sanchez [EMAIL PROTECTED] Date: Mon, 4 Dec 2006 22:37:47 -0800 To: repository@apache.org To: repository@apache.org now it's automatic On 12/4/06, Trustin Lee [EMAIL PROTECTED] wrote: Hello, Please sync the latest release of Apache MINA to the mirrors. The groupId is org.apache.mina. Thank you in advance, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
Re: [2.1.10] WildcardHelperTestCase fails
On Tue, 2006-12-05 at 11:02 +0100, Carsten Ziegeler wrote:
Afaik, the code for the wildcard helper has been replaced after that by
someone else.
Carsten
Bertrand Delacretaz wrote:
Just tried to run the junit tests on BRANCH_2_1_X, and the second
assertion in WildcardHelperTestCase fails:
public void testEndPattern() throws Exception {
WildcardHelper is rotten and has been deprecated in favor of
WildcardMatcherHelper.
However, WildcardHelper is still used by CocoonBean and portal's
UserRightService. Anyone who knows these two classes and could clean
them out?
Also there are two distinct copies of WildcardHelperTestCase in
src/test/org/apache/cocoon/util/test and
src/test/org/apache/cocoon/matching/helpers which both should go.
Cheers, Alfred.
Re: Building changes into the top level sitemap
Jeremy Quinn wrote: Documentation would really help. Absolutely! I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. However, many perceive 2.2 as almost unusable. It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? IIUC, the users should not build cocoon 2.2, they will just use maven to fetch an archetype, write their sitemaps and stuff there, configure their dependencies, and then use again maven to build it. Maven will fetch cocoon core, all the needed blocks, and produce a war or launch jetty with it. Sorry this is in no way intended as a personal criticism, merely a statement of facts as I perceive them. Same here, nothing wrong at all with the incredible work that has been made on 2.2. The real problem at the moment, in my opinion, are not the users, but the *developers*. I've been using 2.2 in last 4 months, experimenting with it a lot, but still don't know how many things work, things changes continuously, and we (even committers) don't know what still has to be done and how. It's not a matter of code by itself, or maven, or osgi. From my PoV, the areas most urgently in need of documentation are : A cookbook for how to develop 2.2 (as you describe) Recipes for starting your own project. Troubleshooting hint for solving common build problems. Again, absolutely, and I'd like to add also : A clear and detailed roadmap to 2.2 Currently about 3 to 5 people are *really working* on 2.2. Many other people (me for example) would like to contribute more, but we don't know exactly what has to be done. It would be a good idea, IMO, to stop developing for a few days, share knowledge with others (documentation and roadmap), assign roles to people (by block?), so that the 3/4 days lost by a small group in producing documenta can be recovered by a joint effort of more people. WDYT? Simone
Re: Building changes into the top level sitemap
Jeremy Quinn wrote:
On 5 Dec 2006, at 14:04, Daniel Fagerstrom wrote:
Jeremy Quinn skrev:
Hi Guys
I am trying to get support for the new Upload Progress Bar working
in Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Yes, that should be the place.
Good :)
Next I am trying to get this compiled in, so that it is available
for the 'cocoon-dist-samples' and everything else that may be built
from this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
First, the dist samples (cocoon-dist-samples, cocoon-dist- publishing)
are really just distribution samples. They just unpack and package
together the cocoon-webapp and samples and implementations from the
various blocks. For development of samples it would be really
inconvenient to work from the dist samples as you would need to
rebuild about the whole trunk after each change.
OK
So what I would recommend to do is to start from the cocoon-webapp
instead and to add (locally) all the block samples you need for your
work, as dependencies to cocoon-webapp. What happens then is that
during startup Cocoon will find all the COB-INF directories from the
block samples from the class path. From here two different things can
happen: if the block is in a jar at the class path, the COB-INF
directory of the block will be unpacked in a blocks/ blockname
directory in the temp directory of the servlet container. If the
block is in a class directory (if you devolop in Eclipse e.g. and
your cocoon-webapp depends on another block project), Cocoon will
read directly from the block without any unpacking.
All this is done by using a new blockcontext protocol that is aware
of the locations of the blocks (see http://marc.theaimsgroup.com/?
l=xml-cocoon-devm=116326232408386w=2).
So the above should hopefully make it easier to work on making the
new stuff functional. After that you can try to compile the dist
samples and see if it works in them as well.
The above described functionality actually make it easier and faster
than ever to develop samples, as you can test them without any
copying or jetty restarts at all in Eclipse. But some documentation
about this would probably not hurt ;)
Documentation would really help.
I have just been working on an established project that is built from
2.2 and I could see the advantages of the new platform.
However, many perceive 2.2 as almost unusable. It clearly is being used
but the procedures are very different from 2.1 . the results can be
completely unpredictable . it will compile one minute and not the
next, this is very off-putting. If the less experienced developers like
myself cannot feel confidant with the build system for 2.2 what hope do
we have of users embracing it?
Sorry this is in no way intended as a personal criticism, merely a
statement of facts as I perceive them.
From my PoV, the areas most urgently in need of documentation are :
A cookbook for how to develop 2.2 (as you describe)
Recipes for starting your own project.
I am trying to learn and compile information in that direction (Recipes).
e.g. in How to run block built with cocoon-22-archetype-block thread
Reinhard suggested me a Getting started in 5 minutes document that
explains how to connect to another block and how to use inheritance
would be welcome.
I am not there yet but I am very willing to archieve that in the near
future.
So please bear with my user stupid questions to come :)
Looking forward to test the AJAX upload widget !
Patrick
Troubleshooting hint for solving common build problems.
Reading the Maven2 manual as Giacomo suggested, may well help :) but
that still leaves understanding how 2.2 performs it's built using Maven.
Thanks for your reply :)
regards Jeremy
HTML mails (was Re: Building changes into the top level sitemap)
Mark Lundquist wrote: On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it /is/ nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) snip/ Mark, from time to time you send mails in HTML. Can you please make sure you send mails in plain text to the list? It will ease the reader's job, as HTML indentation doesn't make it easy to distinguish quoted messages (and also increases the mail's size). Thanks, Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Building changes into the top level sitemap
Simone Gianni skrev: Jeremy Quinn wrote: Documentation would really help. Absolutely! I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. However, many perceive 2.2 as almost unusable. It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? IIUC, the users should not build cocoon 2.2, they will just use maven to fetch an archetype, write their sitemaps and stuff there, configure their dependencies, and then use again maven to build it. Maven will fetch cocoon core, all the needed blocks, and produce a war or launch jetty with it. That is normally correct. Right now a user need to compile as there are so many improvements that simplifies usage since the last milestone. But we will hopefully get a new milestone release in the near future. This will make it as easy as you described above to use Cocoon. Another thing that would simplify it for developers to start work with Cocoon 2.2 would be if we went back to have a cocoon-webapp that actually does something. Now we instead have the dist samples that put everything together in a war file. But they are somewhat unstable and as I described in a previous mail, completely unusable for sample development. The cocoon-webapp doesn't contain any samples anymore, so a develper doesn't have any good examples on what a Cocoon development environment looks like anymore. I would propose that we either add some samples to the cocoon-webapp again or that we create some cocoon-sample-webapp to Cocoon that contains some samples. Sorry this is in no way intended as a personal criticism, merely a statement of facts as I perceive them. Same here, nothing wrong at all with the incredible work that has been made on 2.2. The real problem at the moment, in my opinion, are not the users, but the *developers*. I've been using 2.2 in last 4 months, experimenting with it a lot, but still don't know how many things work, things changes continuously, and we (even committers) don't know what still has to be done and how. To my knowledge nothing _has_ to be done on the code. It is perfectly usable as is (although there are of course room for plenty of improvements). What needs to be done is documenting how to use it. And that more people start to use it so that we can find bugs, stabilize it and smoothen ease of usage. It's not a matter of code by itself, or maven, or osgi. OSGi is not used at all, currently. From my PoV, the areas most urgently in need of documentation are : A cookbook for how to develop 2.2 (as you describe) Recipes for starting your own project. Troubleshooting hint for solving common build problems. Agree. Again, absolutely, and I'd like to add also : A clear and detailed roadmap to 2.2 When I have asked earlier no one had any outstanding items that we absolutely must solve. What is lacking is documentation. So what we need is a roadmap for documentation. In some sense we have that also: one can browse http://cocoon.zones.apache.org/dev-docs/ and see what is lacking. There are lots of skeleton documents, so it is just to start filling in the empty sections ;) Much of that can be done by moving documentation from 2.1 to the new documentation and correct it if needed. It is still hard to know where to start. For me at least some kind of documentation road map or priority list would be helpful. So that I could start with what is most important. /Daniel
Re: [RT] Improved matching selecting
On Tue, 2006-12-05 at 07:58 -0800, Mark Lundquist wrote: On Dec 4, 2006, at 12:46 PM, Alfred Nathaniel wrote: Or use different tags, say in resemblance to XSLT: map:if path=... ... /map:if map:choose map:when path=... I'm not so keen on that, 'cause I'm actually trying to get away from using 2 different elements for this. Rationale: 1) The precedent of match and select would have conditioned users to interpret if and choose as referring to two different kinds of sitemap components (Iffers and Choosers? :-). I'd like the syntax to emphasize that it's all matching and there is only one component now, The Matcher. There is no need for a one-to-one relation between sitemap tags and components. (There won't be any Whener in your model either?). So I don't see the problem in using Matcher implementations for more than one tag which is not called map:match. 2) The sitemap language is not XSLT and has nothing to do with XSLT. The only relationship is that the sitemap has to do with Cocoon and Cocoon uses XSLT... big deal! :-) Trying to imitate XSLT in the sitemap in the interest of familiarity IMHO is misguided and results in confusion. Things that are different should look and feel different. For example: in XSLT if and choose, the @test clause contains a predicate. This is fundamentally different then in the sitemap, where the corresponding attribute contains a pattern, and the predicate comprises some kind of (implicit or configured) match of this pattern against a configured target value. Now the way this is expressed in the classic sitemap, the select/when version puts this value into an attribute called test — probably, again, in deference to XSLT, and IMHO confusing — while the match version puts it in an attribute called pattern. But in either case, the semantics are rather different than XSLT owing to the difference between predicate and pattern. Well, why not really use XSLT syntax? map:if test=wcmatch(uri(), '**/*.xml' where wcmatch() and uri() are Cocoon components. 3) I think XSLT got it wrong :-). They should have used something like xsl:cond for both, and treated @test like I treat @value in my proposal. An analogy between xsl:choose and a switch or case statement is flawed, the correct analogy is to if()... else if() — again, because of the distinction between predicate and pattern! Switch/case is really like today's map:select!!! if()... inaugurates a conditional using the same keyword regardless of how many alternatives there are — one, or many. That's how sitemap matching (which has only patterns) should do it, and that's how XSLT (which has only predicates) should have done it. No need for two different keywords. I think we should use two different keywords because otherwise the content model depends on the presence of various attributes and not on the tagname only -- that is really confusing. Whether the keyword pair is match/select or if/choose or cond/switch or something else I don't care too much. cheers and thx for the feedback :-), —ml— Cheers, Alfred.
Re: Releases from trunk
Reinhard Poetz wrote: I think it's time to release the next milestone of some of our modules: - org.apache.cocoon:cocoon(pom) - org.apache.cocoon:cocoon-core-modules (pom) - org.apache.cocoon:cocoon-core (jar) - org.apache.cocoon:cocoon-blocks-modules (pom) - org.apache.cocoon:cocoon-template (pom) - org.apache.cocoon:cocoon-flowscript (pom) - org.apache.cocoon:cocoon-template-impl (jar) - org.apache.cocoon:cocoon-flowscript-impl(jar) - org.apache.cocoon:cocoon-blocks-fw (pom) - org.apache.cocoon:cocoon-blocks-fw-impl (jar) - org.apache.cocoon:cocoon-tools-modules (pom) - org.apache.cocoon:cocoon-archetypes (pom) - org.apache.cocoon:cocoon-22-archetype-block (archetype jar) That's the minimal set of artifacts to do something useful with Cocoon and to follow the getting started guide. I know that we should release some more blocks (forms, fop, apples, etc.) and the archetype-webapp artifact, but they need some more polishing. I propose that we change the release procedure this time: The person who performs the release, releases the artifacts into our staging repository. Then he calls for a vote, open for 72 hours. If the vote passes, the artifacts are moved to the official Apache sync directory on people.apache.org. The last step is asking on repository@apache.org to sync with the Maven central repo. Is the list of artifacts and the outlined release procedure okay for everybody? If yes, I can do the relase on Thuesday, starting in the afternoon (MET). I am not clear about what is being suggested for this plan. If it is a milestone then it should not end up on the public central repository. If it is a release then it should be accompanied by the sources, etc. Also it should be on the w.a.o/dist mirrors as well as whatever Maven does. http://www.apache.org/dev/release.html#releases http://www.apache.org/dev/#releases -David
Re: [SURVEY] cocoon eventcache block
Ard Schrijvers wrote: Hello, I am wondering if there is anybody using the cocoon eventcache block (without using hippo jars), or are planning to do so in the future? I'm planning to in the near future.
Re: HTML mails (was Re: Building changes into the top level sitemap)
On Dec 5, 2006, at 2:49 PM, Sylvain Wallez wrote: Mark Lundquist wrote: On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it /is/ nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) snip/ Mark, from time to time you send mails in HTML. Can you please make sure you send mails in plain text to the list? It will ease the reader's job, as HTML indentation doesn't make it easy to distinguish quoted messages. Ugh, yeah I see what you mean from the snip above. It's actually not HTML email, though... it's a multipart plaintext + RTF email. I see you are using Thunderbird, so... just for fun I fired up Mozilla, brought up the Gmane usenet mirror in the newreader and looked at my message (the one you replied to), and sure enough, it was doing the indenting thing. It appears that Mozilla/T-bird just doesn't render the RTF excerpt element in a very useful way, and does not let you configure anything different. Interestingly, plaintext email w/ quoted excerpts using the standard style displays beautifully; Mozilla translates that into a nice gray bar running along the side. You can configure Mozilla to default to that just by checking View Message Body As Plain Text. Try it and then look at my message again, and you should see that it looks just right. cheers, —ml—
Re: [Cocoon Wiki] Update of Riester by Riester
Joerg Heinicke escribió: I'd have removed the link to not give the spam more success by adding it to further mailing list archives. Clever move! ;) Thanks for providing info about this stuff. I had no idea what it is at all. Initially, I though the site was a cocoon based site, but the html code did not convinced me at all. Anyhow I preferred to check with you folks formore input. I've just removed the page and added anti-spam keywords. I hope it will be enough. :) Best Regards, Antonio Gallardo.
[jira] Updated: (COCOON-1962) Numeric based suggestion list should initialzate to the corresponding suggested text.
[ http://issues.apache.org/jira/browse/COCOON-1962?page=all ] Antonio Gallardo updated COCOON-1962: - Summary: Numeric based suggestion list should initialzate to the corresponding suggested text. (was: Suggestion List initialization improvement) Description: Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. was: Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. Numeric based suggestion list should initialzate to the corresponding suggested text. - Key: COCOON-1962 URL: http://issues.apache.org/jira/browse/COCOON-1962 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.10-dev (current SVN) Reporter: carlos chávez Assigned To: Antonio Gallardo Attachments: CFormsSuggest.txt, CFormsSuggestSample.txt Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1962) Numeric based suggestion list should initialzate to the corresponding suggested text.
[ http://issues.apache.org/jira/browse/COCOON-1962?page=all ] Antonio Gallardo closed COCOON-1962. Fix Version/s: 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. Feel free to reopen the issue if needed. Numeric based suggestion list should initialzate to the corresponding suggested text. - Key: COCOON-1962 URL: http://issues.apache.org/jira/browse/COCOON-1962 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.10-dev (current SVN) Reporter: carlos chávez Assigned To: Antonio Gallardo Fix For: 2.1.10-dev (current SVN) Attachments: CFormsSuggest.txt, CFormsSuggestSample.txt Hello, If we have a list with a numeric value and a suggested string text, when the form load at the first time is showing the numeric value instead the corresponding text. This patch improve the suggestion list to retrieve the corresponding suggested text from the server when we have the numeric value when we load the form. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [2.1.10] WildcardHelperTestCase fails
On 12/5/06, Alfred Nathaniel [EMAIL PROTECTED] wrote: ...Also there are two distinct copies of WildcardHelperTestCase in src/test/org/apache/cocoon/util/test and src/test/org/apache/cocoon/matching/helpers which both should go... You mean remove the test cases? I wouldn't do that unless the tested classes are not used anymore. Right now, we could just comment out the failing test, which would have failed on previous releases anyway IIUC (the WildcardHelperTestCase didn't exist in 2.1.9). -Bertrand
Re: svn commit: r482168 - in /cocoon/branches/BRANCH_2_1_X: legal/ lib/optional/
Andrew Savory wrote: Hi, On 4 Dec 2006, at 08:27, [EMAIL PROTECTED] wrote: Author: cziegeler Date: Mon Dec 4 05:27:17 2006 New Revision: 482168 URL: http://svn.apache.org/viewvc?view=revrev=482168 Log: Update to released version of jackrabbit Just curious - Jackrabbit released 1.1.1 yesterday, did you mean to add that rather than 1.0.1? No :) We had an unreleased version of jackrabbit before; as I I'm not sure yet what the difference between 1.0.x and 1.1.x are, I just choose the version which should be more compatible to the version we already had. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.1.10] WildcardHelperTestCase fails
Bertrand Delacretaz wrote: On 12/5/06, Alfred Nathaniel [EMAIL PROTECTED] wrote: ...Also there are two distinct copies of WildcardHelperTestCase in src/test/org/apache/cocoon/util/test and src/test/org/apache/cocoon/matching/helpers which both should go... You mean remove the test cases? I wouldn't do that unless the tested classes are not used anymore. Right now, we could just comment out the failing test, which would have failed on previous releases anyway IIUC (the WildcardHelperTestCase didn't exist in 2.1.9). Ok, I removed the usage of the deprecated matching code and replaced it with using the new matcher. In addition I removed the duplicate test case for the WildcardHelper class and commented out the failing test in the remaining test case. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
