[ http://issues.apache.org/jira/browse/COCOON-1683?page=all ]
Ralph Goers updated COCOON-1683:
The patch has been applied to the 2.1 branch. Please cross check and close
> Allow configuration of expiry in EHDefaultStore
> ---
I found this bug report for regexp with many duplicates. Apparently it
is pretty popular. I guess Vadim is aware of this. :-)
The bug is closed as WONTFIX.
http://issues.apache.org/bugzilla/show_bug.cgi?id=764
Ralph Goers wrote:
I cannot believe this didn't get a stack overflow exception
I cannot believe this didn't get a stack overflow exception. We just
happened to request a stack trace of a test system at this time.
I also find myself wondering if EncodeURLTransformer shouldn't be
changed somehow.
"http-8088-Processor20" daemon prio=1 tid=0x8a3b8408 nid=0xf55 runnable
[8a
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Sylvain Wallez wrote:
Date: Fri, 13 Jan 2006 23:11:12 +0100
From: Sylvain Wallez <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [VOTE] Stable CForms
Sylvain Wall
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Sylvain Wallez wrote:
Date: Fri, 13 Jan 2006 23:11:12 +0100
From: Sylvain Wallez <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: [VOTE] Stable CForms
Sylvain Wallez wrote:
Vadim Grit
[ X] +1, Let's do it!
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Please vote to mark CForms as stable, to be included in imminent
2.1.9 release:
[ ] +1, Let's do it!
[X] 0, What is CForms?
[ ] -1, It's not stable, because...
Nobody noticed it (of thought of a typo?)... It's of course
[X] +1, Let's do it!
S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Reinhard Poetz wrote:
Date: Fri, 13 Jan 2006 21:56:10 +0100
From: Reinhard Poetz <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's poin
Giacomo Pati schrieb:
I've missed to place the dependant jars of a block. So I propose they
go to META-INF/lib with no strong agruments for it but they are needed
to setup the classloader for the block or to populate the parent
classloader and that's done at initialization time.
WDYT?
IMO
Hello,
I have a problem when updating my branch:
A src\blocks\ajax
A src\blocks\ajax\conf
...
Fetching external item into 'src\blocks\ajax'
svn: Working copy 'src\blocks\ajax' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
Could it be that the director
Giacomo Pati schrieb:
I've missed to place the dependant jars of a block. So I propose they go
to META-INF/lib with no strong agruments for it but they are needed to
setup the classloader for the block or to populate the parent
classloader and that's done at initialization time.
WDYT?
Acco
Jean-Baptiste Quenot wrote:
> * Ralph Goers:
>
>
>>I don't see a corresponding email for trunk. Was this also
>>applied there?
>
>
> Not yet. Is it urgently needed in 2.2?
No, but if you don't do it now, likely it will be forgotten.
Regards, Upayavira
Joerg Heinicke wrote:
On 13.01.2006 17:37, Ralph Goers wrote:
I don't see a corresponding email for trunk. Was this also
applied there?
Not yet. Is it urgently needed in 2.2?
I have no idea. It is good practice to apply patches to both branches
just
so it doesn't get forgotten.
O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Reinhard Poetz wrote:
Date: Fri, 13 Jan 2006 19:20:43 +0100
From: Reinhard Poetz <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user's poin
On 13.01.2006 11:17, Sylvain Wallez wrote:
[x] move template block to 2.1 and keep the old implementation
[ ] move template block to 2.1 and trash the old implementation
[ ] don't move template block to 2.1
Jörg
On 13.01.2006 16:32, Vadim Gritsenko wrote:
We need official vote to mark CForms stable, so let's start it. Please
vote to mark CForms as stable, to be included in imminent 2.1.9 release:
[x] +1, Let's do it!
[ ] 0, What is CForms?
[ ] -1, It's not stable, because...
Jörg
Giacomo Pati wrote:
Ok, seems like we need a structured proposal :-)
1. All files needed at deployment time should go into META-INF
- block.xml
- block.xconf
- xconf/*.xconf (includes? do we need more that one .xconf for a
block?)
- block.xlog (if we do have logging support)
On 13.01.2006 17:37, Ralph Goers wrote:
I don't see a corresponding email for trunk. Was this also
applied there?
Not yet. Is it urgently needed in 2.2?
I have no idea. It is good practice to apply patches to both branches just
so it doesn't get forgotten.
Otherwise it should go int
Daniel Fagerstrom wrote:
> I'm certain that the hot deploy feature is usefull, see [2]. My problem
> was that I wanted to debug the cocoon-blocks-fw-sample, and here the
> code that I actually want to debug is in the project
> cocoon-blocks-fw-impl that is added as a jar to the webapp in
> cocoon-
Ralph Goers wrote:
Jean-Baptiste Quenot said:
* Ralph Goers:
I don't see a corresponding email for trunk. Was this also
applied there?
Not yet. Is it urgently needed in 2.2?
I have no idea. It is good practice to apply patches to both branches just
so it doesn't
Jasha Joachimsthal wrote:
I built Cocoon 2.1.8. on Windows XP with J2SDK 1.4.2_09, added JavaMail 1.3.1 and Activation 1.0.2 from Sun.
When I try to use the SendMailTransformer, it only tries to connect to localhost on port
25. It doesn't matter if I change the smtp-host or smtp-post values i
Vadim Gritsenko wrote:
We need official vote to mark CForms stable, so let's start it. Please
vote to mark CForms as stable, to be included in imminent 2.1.9 release:
[ ] +1, Let's do it!
[ ] 0, What is CForms?
[ ] -1, It's not stable, because...
I am +1. Also we need to fix the cforms l
[ http://issues.apache.org/jira/browse/COCOON-1683?page=all ]
Ralph Goers reopened COCOON-1683:
-
> Allow configuration of expiry in EHDefaultStore
> ---
>
> Key: COCOON-1683
> URL: http://iss
Jean-Baptiste Quenot said:
> * Ralph Goers:
>
>> I don't see a corresponding email for trunk. Was this also
>> applied there?
>
> Not yet. Is it urgently needed in 2.2?
I have no idea. It is good practice to apply patches to both branches just
so it doesn't get forgotten.
Ralph
Jean-Baptiste Quenot said:
> * Ralph Goers:
>
>
> MayI suggestthatyou setthe buildproperty
> exclude.webapp-test-suite=true in local.build.properties once I
> commit my change?
I can live with that. Forget the -1.
Ralph
Vadim Gritsenko said:
> Sylvain Wallez wrote:
>> Carsten Ziegeler wrote:
>>>
>>> As soon as forms is really called and *treated* as stable: +1
>>
>> As I said previously, the number of CForms users is such that any change
>> will have to be backwards compatible.
>>
>> I removed v2 and v3 as the
> -Original Message-
> From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED]
> Sent: vrijdag 13 januari 2006 16:47
> To: dev@cocoon.apache.org
> Subject: Re: Cocoon 2.1.8 and SendMailTransformer
>
>
> * Jasha Joachimsthal:
>
> > Later I excluded lib/optional/geronimo-spec-javamail-1.3.1-r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Vadim Gritsenko wrote:
[X] +1, Let's do it!
[ ] 0, What is CForms?
[ ] -1, It's not stable, because...
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.co
* Ralph Goers:
> I don't see a corresponding email for trunk. Was this also
> applied there?
Not yet. Is it urgently needed in 2.2?
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
We need official vote to mark CForms stable, so let's start it. Please
vote to mark CForms as stable, to be included in imminent 2.1.9 release:
[ ] +1, Let's do it!
[ ] 0, What is CForms?
[ ] -1, It's not stable, because...
+1
+1 too
-
Vadim Gritsenko wrote:
Please vote to mark CForms as stable, to be included in imminent 2.1.9
release:
[ ] +1, Let's do it!
[X] 0, What is CForms?
[ ] -1, It's not stable, because...
Sylvain
--
Sylvain WallezAnyware Technologies
http://bluxte.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, seems like we need a structured proposal :-)
1. All files needed at deployment time should go into META-INF
- block.xml
- block.xconf
- xconf/*.xconf (includes? do we need more that one .xconf for a
block?)
- block.xlog (if we d
Jorg Heymans wrote:
Giacomo Pati wrote:
[X] move template block to 2.1 and keep the old implementation
Deprecate old implementation (if possible) and remove it from 2.2 (if it
is still there).
same here.
same here too.
Bye, Helma
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Giacomo Pati wrote:
In Reinhards document it is META-INF/block.xml on the Wiki it's
COB-INF/block.xml. So we need to make a decision:-)
Please use META-INF/block.xml, AFAIK we agreed on making our blocks
valid JAR files.
Any zip file with ja
Vadim Gritsenko wrote:
[ ] +1, Let's do it!
[ ] 0, What is CForms?
[ ] -1, It's not stable, because...
+1 - been stable for a long time as far as I am concerned ;-)
Ross
* Jasha Joachimsthal:
> Later I excluded lib/optional/geronimo-spec-javamail-1.3.1-rc5.jar
Have you tried with Sun's mail.jar? geronimo-spec-javamail is
known not to work properly.
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Vadim Gritsenko wrote:
> [X] +1, Let's do it!
> [ ] 0, What is CForms?
> [ ] -1, It's not stable, because...
>
Jorg
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> As soon as forms is really called and *treated* as stable: +1
>>
>>
>> As I said previously, the number of CForms users is such that any
>> change will have to be backwards compatible.
>>
>> I removed v2 and v3
* Ralph Goers:
> This is fine as long as they don't end up in the webapp that
> gets built when you do a build.sh war or webapp.
By default, the test suite is not excluded.
> > I intend to modify the build to copy cocoon-testcase.jar into
> > the webapp, so that the test-suite can use t
Vadim Gritsenko wrote:
We need official vote to mark CForms stable, so let's start it. Please
vote to mark CForms as stable, to be included in imminent 2.1.9 release:
[ ] +1, Let's do it!
[ ] 0, What is CForms?
[ ] -1, It's not stable, because...
+1
/Daniel
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
As soon as forms is really called and *treated* as stable: +1
As I said previously, the number of CForms users is such that any change
will have to be backwards compatible.
I removed v2 and v3 as the (unnamed) v1 should be the official API,
[
http://issues.apache.org/jira/browse/COCOON-1731?page=comments#action_12362651
]
Jason Johnston commented on COCOON-1731:
I can verify this is a problem. I brought it up on the developers mailing list
a few months ago but I didn't follow up. JX
Unable to create a new JXParthBinding outside the
org.apache.cocoon.forms.binding package
-
Key: COCOON-1731
URL: http://issues.apache.org/jira/browse/COCOON-1731
Project: Cocoon
I'm certain that the hot deploy feature is usefull, see [2]. My problem
was that I wanted to debug the cocoon-blocks-fw-sample, and here the
code that I actually want to debug is in the project
cocoon-blocks-fw-impl that is added as a jar to the webapp in
cocoon-blocks-fw-sample, when I run mvn
I'm still a little unclear about how SourceValidities and non-caching
pipelines work. The way I believe it works is that non-caching
pipelines are always considered to be invalid and their content is
recreated. I believe then that if a parent pipeline aggregates (by any
of the aggregation tec
Daniel Fagerstrom wrote:
> Even if the Jetty6 plugin for Maven is an important step, the jar
> copying in mvn war:inplace, doesn't give the right snappy feeling for
> Cocoon core development.
Is its hot-deploy feature useable at all ? It's described on their
website [1].
HTH
Jorg
[1] http://j
Sylvain Wallez wrote:
[ ] move template block to 2.1 and keep the old implementation
Nitpicking... 'Move' implies it will be removed from 2.2... So:
[X] add template block to 2.1 and keep the old jxtg implementation
Vadim
Bertrand Delacretaz wrote:
Le 13 janv. 06, à 00:24, Ralph Goers a écrit :
I would like to propose a 2.1.9 release...
+1
+1
I also thought about releasing a "publishing edition", a binary with
blocks which are useful for basic XML to HTML/PDF/SVG publishing enabled.
As a start, you can s
Jean-Baptiste Quenot wrote:
* Sylvain Wallez:
Leszek Gawron wrote:
roy huang wrote:
In current 2.1.x svn ,Forms using JXTemplateGenerator is
much slower than FormTransformer
For 2.1.x it is probably true because it still contains
unrefactored version of jxtg.
So what
Reinhard Poetz wrote:
Giacomo Pati wrote:
In Reinhards document it is META-INF/block.xml on the Wiki it's
COB-INF/block.xml. So we need to make a decision:-)
Please use META-INF/block.xml, AFAIK we agreed on making our blocks
valid JAR files.
Any zip file with jar extension and /META-INF/M
I built Cocoon 2.1.8. on Windows XP with J2SDK 1.4.2_09, added JavaMail 1.3.1
and Activation 1.0.2 from Sun.
When I try to use the SendMailTransformer, it only tries to connect to
localhost on port 25. It doesn't matter if I change the smtp-host or smtp-post
values in the sitemap, the XML file
Sylvain Wallez wrote:
Hi all,
The template block in trunk is a widely improved replacement for the
original JXTG, both in terms of performance and code mantainability. We
discussed several times about moving it to 2.1 with positive answers,
and it's now time to make a formal decision on this
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Agree about not using Castor for the blocks framework. On the same
time it would be better to have a common model, but I don't know how
to best achieve that.
Yes, I was also thinking about this. The best (or even better)
alternative istXMLBean
I don't see a corresponding email for trunk. Was this also applied there?
[EMAIL PROTECTED] wrote:
Author: jbq
Date: Fri Jan 13 03:27:18 2006
New Revision: 368690
URL: http://svn.apache.org/viewcvs?rev=368690&view=rev
Log:
Fix COCOON-1259: XMLDBTransformer can use username/password to access X
Sylvain Wallez wrote:
Hi all,
The template block in trunk is a widely improved replacement for the
original JXTG, both in terms of performance and code mantainability.
We discussed several times about moving it to 2.1 with positive
answers, and it's now time to make a formal decision on th
Jean-Baptiste Quenot wrote:
* Jean-Baptiste Quenot:
* Ralph Goers:
These classes are for unit testing.
Exactly. And part of my tests involve classes running in the
webapp.
Stuff that goes in the webapp is in the samples directory.
What are you wanting to do?
Even if the Jetty6 plugin for Maven is an important step, the jar
copying in mvn war:inplace, doesn't give the right snappy feeling for
Cocoon core development. I wanted to start the Webserver in Eclipse
instead, and found a Jetty plugin http://jettylauncher.sourceforge.net/.
Besides installin
Sylvain Wallez wrote:
Hi all,
The template block in trunk is a widely improved replacement for the
original JXTG, both in terms of performance and code mantainability. We
discussed several times about moving it to 2.1 with positive answers,
and it's now time to make a formal decision on this
I posted this in the user list without any feedback so I'm trying here. I'm
running a periodic background process to maintain data in eXist.
I'm using Cocoon 2.1.7 and have set up a schedule to run every minute by
setting up a trigger in cocoon.xconf:
0 0/1 * * * ? *
The trigger execut
Giacomo Pati wrote:
On Fri, 13 Jan 2006, Daniel Fagerstrom wrote:
Date: Fri, 13 Jan 2006 11:19:26 +0100
From: Daniel Fagerstrom <[EMAIL PROTECTED]>
...
block.xml contains or point to the block.xconf, so it can be place
anywhere.
I haven't found any formal specification about this "point
Giacomo Pati wrote:
>>> [X] move template block to 2.1 and keep the old implementation
>
> Deprecate old implementation (if possible) and remove it from 2.2 (if it
> is still there).
>
same here.
Jorg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Daniel Fagerstrom wrote:
Date: Fri, 13 Jan 2006 11:19:26 +0100
From: Daniel Fagerstrom <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Block deployment: working with blocks from a user'
[ http://issues.apache.org/jira/browse/COCOON-1639?page=all ]
Jean-Baptiste Quenot updated COCOON-1639:
-
Attachment: cocoon.log
Jetty log with stacktrace
> [patch] NekoHTMLTransformer
> ---
>
> Key: COCOON-1639
>
[
http://issues.apache.org/jira/browse/COCOON-1639?page=comments#action_12362632
]
Jean-Baptiste Quenot commented on COCOON-1639:
--
Thanks for your contribution, looks nice. However:
1) In src/blocks/html/samples/sitemap.xmap, I replaced in p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 13 Jan 2006, Sylvain Wallez wrote:
[X] move template block to 2.1 and keep the old implementation
Deprecate old implementation (if possible) and remove it from 2.2 (if it
is still there).
[ ] move template block to 2.1 and trash the ol
Il giorno 13/gen/06, alle ore 11:17, Sylvain Wallez ha scritto:
[X ] move template block to 2.1 and keep the old implementation
For 2.1.9, I say keep the old one and release 2.1.9 ASAP. If
everything is OK, we can ditch the old one in 2.1.10.
Ugo
--
Ugo Cei
Tech Blog: http://agy
[
http://issues.apache.org/jira/browse/COCOON-1603?page=comments#action_12362631
]
Jean-Baptiste Quenot commented on COCOON-1603:
--
Thanks for your contribution Eric. Can you tell if this change is backwards
compatible? Have you seen http://i
[ http://issues.apache.org/jira/browse/COCOON-1259?page=all ]
Jean-Baptiste Quenot closed COCOON-1259:
Resolution: Fixed
See http://svn.apache.org/viewcvs.cgi?view=rev&rev=368690
Note that DatabaseManager.getCollection() accepts null values
[X] move template block to 2.1 and keep the old implementation
[ ] move template block to 2.1 and trash the old implementation
[ ] don't move template block to 2.1
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Subject says it all, but with the move to Maven in full motion now I
assume you're likely to forget this.
Bye, Helma
David Nuescheler wrote:
hi sylvain,
does this help?
http://www.day.com/maven/jsr170/licenses/day-spec-license.htm
I found that one, but IANAL and I can't say if this text allows
redistribution with an Apache-licenced product... I guess Roy should be
able to tell us.
if i can do anythin
Daniel Fagerstrom wrote:
Sylvain Wallez skrev:
Hi all,
The template block in trunk is a widely improved replacement for the
original JXTG, both in terms of performance and code mantainability.
We discussed several times about moving it to 2.1 with positive
answers, and it's now time to make
[ http://issues.apache.org/jira/browse/COCOON-1248?page=all ]
Jean-Baptiste Quenot closed COCOON-1248:
Resolution: Fixed
Thanks for your contribution, however this problem has been fixed inbetween.
See http://svn.apache.org/viewcvs.cgi?rev=
[ http://issues.apache.org/jira/browse/COCOON-1066?page=all ]
Jean-Baptiste Quenot closed COCOON-1066:
Resolution: Duplicate
About dn-element, what is it supposed to do? We did not receive feedback on
this.
About securityprotocol, can you
[
http://issues.apache.org/jira/browse/COCOON-1526?page=comments#action_12362622
]
Jean-Baptiste Quenot commented on COCOON-1526:
--
Nice contribution. However, could you please submit an updated patch, as
utils.patch does not apply to the curr
hi sylvain,
does this help?
http://www.day.com/maven/jsr170/licenses/day-spec-license.htm
if i can do anything else to help, please let me know. it clearly
is our intention that everybody should be able to redistribute the jcr-1.0.jar
regards,
david
Sylvain Wallez wrote:
[X] move template block to 2.1 and keep the old implementation
[ ] move template block to 2.1 and trash the old implementation
[ ] don't move template block to 2.1
That's IMO the safest thing to do in the maintenance branch.
Sylvain
--
Sylvain Wallez
Sylvain Wallez skrev:
Hi all,
The template block in trunk is a widely improved replacement for the
original JXTG, both in terms of performance and code mantainability. We
discussed several times about moving it to 2.1 with positive answers,
and it's now time to make a formal decision on this
Carsten Ziegeler wrote:
Antonio Gallardo wrote:
Ralph Goers wrote:
I would like to propose a 2.1.9 release. It has been about 2 months
since 2.1.8. We are needing to upgrade and I would really need to
pick up the mapping file changes I made to the portal (this is quite a
serious bug
[ http://issues.apache.org/jira/browse/COCOON-1333?page=all ]
Jean-Baptiste Quenot closed COCOON-1333:
Resolution: Fixed
This issue has fixed in between:
See http://svn.apache.org/viewcvs.cgi?rev=179049&view=rev
Please check with Cocoon 2.
Reinhard Poetz skrev:
Giacomo Pati wrote:
In Reinhards document it is META-INF/block.xml on the Wiki it's
COB-INF/block.xml. So we need to make a decision:-)
Please use META-INF/block.xml, AFAIK we agreed on making our blocks
valid JAR files.
Ok.
...
Now to answer your question ;) the p
Hi all,
The template block in trunk is a widely improved replacement for the
original JXTG, both in terms of performance and code mantainability. We
discussed several times about moving it to 2.1 with positive answers,
and it's now time to make a formal decision on this subject.
To avoid any
* Jean-Baptiste Quenot:
> * Ralph Goers:
>
> > These classes are for unit testing.
>
> Exactly. And part of my tests involve classes running in the
> webapp.
>
> > Stuff that goes in the webapp is in the samples directory.
> > What are you wanting to do?
>
> I don't want my unit tests to
Agree about not using Castor for the blocks framework. On the same time
it would be better to have a common model, but I don't know how to best
achieve that.
>> Yes, I was also thinking about this. The best (or even better) alternative
istXMLBeans but that's also far from being light-weight. ..
Le 13 janv. 06, à 00:24, Ralph Goers a écrit :
I would like to propose a 2.1.9 release...
+1
I also thought about releasing a "publishing edition", a binary with
blocks which are useful for basic XML to HTML/PDF/SVG publishing
enabled.
I know 2.2 will make this much easier, but it wouldn'
Il giorno 13/gen/06, alle ore 00:24, Ralph Goers ha scritto:
I would like to propose a 2.1.9 release. It has been about 2
months since 2.1.8. We are needing to upgrade and I would really
need to pick up the mapping file changes I made to the portal (this
is quite a serious bug) and it wo
David Nuescheler wrote:
Hi,
Anybody knows of one? I've found a jcr-1.0.jar at
http://www.day.com/maven/jsr170/jars/ but I don't want to list the
Day server in our poms.
As far as I am concerned, I would argue that based on the JCP licensing
the "Spec-Lead" of a JSR as the owner of
Jorg Heymans wrote:
> Bertrand Delacretaz wrote:
>
>>Just a nitpick, I noticed that your howto includes the zone password of
>>the maven user, not sure if this is a good idea.
>>
>>Of course the howto is accessible to ASF committers only, but that's a
>>thousand people...until now we've used "su"
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113697649420083&w=2
Why not add new template block to 2.1,using jxtemplate now in form block is
quite slow.
Roy Huang
* Sylvain Wallez:
> Leszek Gawron wrote:
> > roy huang wrote:
> > > In current 2.1.x svn ,Forms using JXTemplateGenerator is
> > > much slower than FormTransformer
> > For 2.1.x it is probably true because it still contains
> > unrefactored version of jxtg.
> So what about adding th
Antonio Gallardo wrote:
> Ralph Goers wrote:
>
>
>>I would like to propose a 2.1.9 release. It has been about 2 months
>>since 2.1.8. We are needing to upgrade and I would really need to
>>pick up the mapping file changes I made to the portal (this is quite a
>>serious bug) and it would be v
Vadim Gritsenko wrote:
> Hi All,
>
> Noticed that SVN trunk is broken:
>
> $ svn proplist .
> Properties on '.':
> subversion/libsvn_subr/subst.c:643: (apr_err=135000)
> svn: Inconsistent line ending style
It was like that for me recently too.
After doing svn up today, i needed to manually
delet
Bertrand Delacretaz wrote:
> Just a nitpick, I noticed that your howto includes the zone password of
> the maven user, not sure if this is a good idea.
>
> Of course the howto is accessible to ASF committers only, but that's a
> thousand people...until now we've used "su" to access the various us
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Module cocoon contains errors.
The current state of this module is 'Success'.
Full detai
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Module cocoon contains errors.
The current state of this module is 'Success'.
Full detai
95 matches
Mail list logo
