Leszek Gawron wrote:
> Previously web.xml properties were read into settings via a hard-wired
> PropertyProvider. I see no property providers implemented now in
> cocoon-core as well as no code reading web.xml elsewhere.
>
> Was this intentional? I have not used the functionality anyways. Just
Hi All from Oz,
We need a virtual colour for those who can't make it but would gladly
share beers :)
M! the first GT I'll miss being at, ever.. :(
On 30/08/2006, at 1:25 AM, Carsten Ziegeler wrote:
Andrew Savory wrote
You should sign up even if you're a potential speaker: it helps to
Previously web.xml properties were read into settings via a hard-wired
PropertyProvider. I see no property providers implemented now in
cocoon-core as well as no code reading web.xml elsewhere.
Was this intentional? I have not used the functionality anyways. Just
trying to keep compatibility.
On 29 Aug 2006, at 23:23, Jorg Heymans wrote:
that would work, but a better solution would be to exclude the
dependency from jackrabbit for now, as the jcr-block pom has a
direct dependency on javax.jcr anyway (1.0.1 though - does it make
a difference?)
I'll fix the pom sometime t
On 29 Aug 2006, at 18:48, Lars Trieloff wrote:
JCR-1.0 is not available in the public repository, JCR-1.0.1 is. As
it's there allright, http://mirrors.dotsrc.org/maven2/javax/jcr/jcr/
1.0/ . Jackrabbit is still using the old jsr170 groupId however.
Jackrabbit's dependencies have not been u
Lars Trieloff wrote:
> JCR-1.0 is not available in the public repository, JCR-1.0.1 is. As
> Jackrabbit's dependencies have not been updated yet, you still have to
> download it and install it manually.
Thanks Lars,
I just excluded the 1.0 version from the jackrabbit dependency and
everything is b
JCR-1.0 is not available in the public repository, JCR-1.0.1 is. As
Jackrabbit's dependencies have not been updated yet, you still have to
download it and install it manually.
Am Dienstag, den 29.08.2006, 18:19 +0200 schrieb Carsten Ziegeler:
> When building latest jcr block, I get:
>
> Missing:
When building latest jcr block, I get:
Missing:
--
1) jsr170:jcr:jar:1.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=jsr170 -DartifactId=jcr \
-Dversion=1.0 -Dpackaging=jar -Dfile=/
Hi,
Carsten Ziegeler wrote:
Indeed, very cool - but I'm still wondering what the different head
colors mean (especially looking at mine...)
I believe it's calculated using a special formula, cooked up by fiendish
and crazy minds within a top-secret laboratory hidden somewhere in
Europe that
is src attribte in map:script handled differently than other src
attributes in sitemap?:
This declaration does not resolve input module references at all.
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://w
Andrew Savory wrote
> You should sign up even if you're a potential speaker: it helps to have
> an idea of numbers for planning at the venue. It also means you get a
> cool dynamically-generated seat on the picture ;-)
>
Indeed, very cool - but I'm still wondering what the different head
colors
[
http://issues.apache.org/jira/browse/COCOON-1903?page=comments#action_12431260
]
Leszek Gawron commented on COCOON-1903:
---
I am already working on the issue. Thanks for help. Also an archetype needs
updating.
> [PATCH] cocoon-block-depl
Hi.
I am the author of this patch. I can confirm the patching language is
the same (as I copied most of it's implementation from the actual ant
task). Sorry for the remaining System.out, it is not necessary from my
point of view, I added it simply for debugging purposes.
regards,
Lars Trieloff
On 8/29/06, Andrew Savory <[EMAIL PROTECTED]> wrote:
It also means you get a
cool dynamically-generated seat on the picture ;-)
I got a seat! Even made it through the Paypal forms in Dutch!
-Bertrand
[ http://issues.apache.org/jira/browse/COCOON-1903?page=all ]
Lars Trieloff updated COCOON-1903:
--
Attachment: cocoon-block-deployer-spring-support.patch
The described patch.
> [PATCH] cocoon-block-deployer does not reflect latest spring configuration
[PATCH] cocoon-block-deployer does not reflect latest spring configuration
changes
--
Key: COCOON-1903
URL: http://issues.apache.org/jira/browse/COCOON-1903
Project: Coco
Hi,
Bertrand Delacretaz wrote:
Do (potential) speakers have to register there as well?
IIRC for the last editions speakers were handled separately, but
whatever's most convenient for the organizing team is fine!
-Bertrand, still thinking about something cool (or funny?) to present
there...
On 8/29/06, Andrew Savory <[EMAIL PROTECTED]> wrote:
...Just a gentle nudge for those that haven't signed up yet: wouldn't you
love to see your name on one of the chairs at
http://www.cocoongt.org/chairs-big.png ?...
Do (potential) speakers have to register there as well?
IIRC for the last ed
Hi,
Arje Cahn wrote:
The EARLY BIRD registration is now open! Hurray!
Sign up soon - be sure to get that seat before someone else does :)
Early bird fee is 99 EUR until September 11th and includes Hackaton fees!
www.cocoongt.org
Just a gentle nudge for those that haven't signed up yet: woul
* Antonio Gallardo:
> Rob Berens escribió:
>
> > I'm using cocoon 2.1.8 and noticed that in some cases memory
> > remains claimed even after continuations have expired.
>
> Would you try the lastest code for the 2.1.x branch. I think it
> should be fixed there.
If that is really the case, I
Leszek Gawron wrote:
Did anyone try to evaluate new rhino version? I have replaced R2 with R3
in cocoon trunk and found out that bean.getId() works as expected while
shortened bean.id returns undefined.
I forgot to mention it occurs in part of the binding
file. The flowscript itself is fine.
Did anyone try to evaluate new rhino version? I have replaced R2 with R3
in cocoon trunk and found out that bean.getId() works as expected while
shortened bean.id returns undefined.
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67
> Will that generated pom be ever replaced in my local repo if spring guys
> provide the final version?
>
The pom is (by mere location amongst others) always bound to an artifact
version, so if the next version of spring provides a pom then that one
will be used.
Also, it is safe to assume that
Leszek Gawron wrote:
Jorg Heymans wrote:
o WTF is going on with the spring downloads? Seems like there is no
pom available, but it works anyway...
You do not need pom to get the jar. Some default stub is being used.
This pisses me a lot (not the fact that it works but that the pom is
missing)
Jorg Heymans wrote:
o WTF is going on with the spring downloads? Seems like there is no
pom available, but it works anyway...
You do not need pom to get the jar. Some default stub is being used.
This pisses me a lot (not the fact that it works but that the pom is
missing) because you have to u
>> o WTF is going on with the spring downloads? Seems like there is no
>> pom available, but it works anyway...
>>
> You do not need pom to get the jar. Some default stub is being used.
> This pisses me a lot (not the fact that it works but that the pom is
> missing) because you have to use offli
Torsten Curdt wrote:
Let's say it has been a while that I've last looked into trunk. So
instead of spending hours finding my way through how things are
suppossed to work I came across a few questions.
o I have some resources in "myBlock/src/main/resources/COB-INF" ...why
don't they appear in "ta
Let's say it has been a while that I've last looked into trunk. So
instead of spending hours finding my way through how things are
suppossed to work I came across a few questions.
o I have some resources in "myBlock/src/main/resources/COB-INF" ...why
don't they appear in "target/myBlock"?
o Do w
28 matches
Mail list logo
