Upayavira wrote:
Reinhard Poetz wrote:
Upayavira wrote:
Well, given Steven is working on setting up Daisy right now, I think
we might need that. How much change would our SVN repo require to
make 0.7 work?
AFAIK our repositories build fine with Forrest 0.7. The person doing
the
[EMAIL PROTECTED] wrote:
Author: reinhard
Date: Sun Jun 5 23:35:20 2005
New Revision: 180239
URL: http://svn.apache.org/viewcvs?rev=180239view=rev
Log:
add Spring library
Modified:
cocoon/trunk/lib/jars.xml
Modified: cocoon/trunk/lib/jars.xml
URL:
Leszek Gawron wrote:
[EMAIL PROTECTED] wrote:
+
+ file id=spring-core
+titleSpring/title
+description
+ Jackrabbit JCR implementation
+/description
+used-bySpring block/used-by
+liboptional/spring-1.1.5.jar/lib
+homepagehttp://www.springframework.org//homepage
Hi Mark,
sorry for being late in replying. Usually weekends are more hectic than
weekdays here.
I cannot grant you editor privileges as Steven is the administrator for
the site. I've asked Steven to fix this. In the mean time, just add
comments to any page and I'll be happy to incorporate the
Reinhard Poetz wrote:
Sylvain Wallez wrote:
snip/
The main principle of the Ajax stuff is that each part of the page
that can be updated asynchronously (not necessarily a widget) must be
fully contained in a tag (span, div, input, whatever) with a unique
id. In the case of widgets, this
In 2.2 we have the nice feature to have a class loader on a per sitemap
base. This allows to load classes just for this sitemap (and all sub
sitemaps).
Now, the implementation - the SitemapLanguage - uses a global
component, the ClassLoaderFactory to get the per sitemap classloader.
Current we
On 06 Jun 2005, at 09:54, Linden H van der (MI) wrote:
Hi Mark,
sorry for being late in replying. Usually weekends are more hectic than
weekdays here.
I cannot grant you editor privileges as Steven is the administrator for
the site. I've asked Steven to fix this. In the mean time, just add
Le 6 juin 05, à 10:28, Steven Noels a écrit :
...That said, we need to discuss access policies to the Daisy instance
on our Cocoon zone. It's only logical committers are granted User
access immediately. What about non-committer documentation
contributors?..
I suggest having a vote here
Does someone care if I would move the ClassLoaderManager to the XSP
block? This component is only used there and is imho not needed by any
other block, so I think it makes sense to move it.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
Le 6 juin 05, à 10:10, Carsten Ziegeler a écrit :
Then you can define the class for the factory on the
components section:
map:components classloader-factory-class=.../
If this attribute is missing we use the default which is the
DefaultClassLoaderFactory
I don't know this part of the
Carsten Ziegeler wrote:
In 2.2 we have the nice feature to have a class loader on a per sitemap
base. This allows to load classes just for this sitemap (and all sub
sitemaps).
Now, the implementation - the SitemapLanguage - uses a global
component, the ClassLoaderFactory to get the per sitemap
Bertrand Delacretaz wrote:
Le 6 juin 05, à 10:28, Steven Noels a écrit :
...That said, we need to discuss access policies to the Daisy
instance on our Cocoon zone. It's only logical committers are granted
User access immediately. What about non-committer documentation
contributors?..
I
Sylvain Wallez wrote:
Can you elaborate on your use case?
I can try :) I don't have a clear concept right now. All I want to do is
to scan the classpath defined for the sitemap for some specific classes
(or perhaps resources - don't know yet). If these classes implement a
specific interface an
Hello,
Yes please, for example, I'd like to add the revised Eclipse
instructions I wrote up over here:
http://wiki.apache.org/cocoon/LoadInEclipse
These instructions are complementary to Helma's getting started
instructions, and I want to add screenshots etc. I don't suppose I can
add these
Hi,
This feels like a stupid question, but what about comments? Do people
adding comments to daisy also need to sign the CLA???!
Mark
On 6 Jun 2005, at 10:27, Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 6 juin 05, à 10:28, Steven Noels a écrit :
...That said, we need to discuss
Mark Leicester wrote:
Hi,
This feels like a stupid question, but what about comments? Do people
adding comments to daisy also need to sign the CLA???!
To my mind that would be overkill. After all, we've got stacks of stuff
on the wiki that isn't covered by a CLA. Comments would fall under
Hi Jorg,
On 19 May 2005, at 20:50, Jorg Heymans wrote:
At the moment, conversations on #cocoon are not logged.
snip/
I still think it is useful to log everything being said there and
include it somewhere for reference.
snip/
Objections? Thoughts?
I'd object because the IRC channel
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 6 juin 05, à 10:28, Steven Noels a écrit :
...That said, we need to discuss access policies to the Daisy
instance on our Cocoon zone. It's only logical committers are granted
User access immediately. What about non-committer documentation
Hello,
I've had a look at Daisy on
http://cocoon.zones.apache.org/daisy/cocooninaction/4.html and found
that my old user account was not transferred, so I re-registered. I
haven't yet received a confirmation email (I registered about 30 mins
ago). Is there a confirmation process for new user
On 06 Jun 2005, at 12:39, Ross Gardler wrote:
In the above model a user is someone who self registered, can write
but not publish. A committer has the role doc-team and can publish.
I could configure the following setup:
* configure the site so that new document versions are saved in the
On 06 Jun 2005, at 13:05, Mark Leicester wrote:
Hello,
I've had a look at Daisy on
http://cocoon.zones.apache.org/daisy/cocooninaction/4.html and found
that my old user account was not transferred, so I re-registered. I
haven't yet received a confirmation email (I registered about 30 mins
Andrew Savory wrote:
I'd object because the IRC channel can contain informal chat as well as
useful reference. IMHO the best way to get useful reference archived is
for summaries of chats that resolve a problem to be posted back to the
mailing list. This lets people talk in an informal
Le 6 juin 05, à 13:21, Steven Noels a écrit :
...I could configure the following setup:
* configure the site so that new document versions are saved in the
draft state
* guests are guest: no access rights except viewing and adding comments
* create a role document contributors which can edit
Steven Noels wrote:
On 06 Jun 2005, at 12:39, Ross Gardler wrote:
In the above model a user is someone who self registered, can write
but not publish. A committer has the role doc-team and can publish.
I could configure the following setup:
* configure the site so that new document
Mark Leicester wrote:
Hi,
This feels like a stupid question, but what about comments? Do people
adding comments to daisy also need to sign the CLA???!
Of course not! They just need to self-register, which gives them the
guest role.
Sylvain
--
Sylvain Wallez
Dear Cocoon Devs,
My Name is Max Pfingsthorn, I currently study for my Master of Science in
Artificial Intelligence at the University of Amsterdam, The Netherlands. You
can have a look at my CV (last updated Dec.2004) here:
http://student.science.uva.nl/~mpfingst/cv/CV.Max.Pfingsthorn.pdf.
I
We recently discussed the famous logging topic [1] and it seems
that we agree to reduce the dependencies to LogKit.
So, please cast your votes on the following:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through which LogKit can be
On 06 Jun 2005, at 13:55, Ross Gardler wrote:
Really? That could be a real problem for getting folks to contribute
to the docs. It implies that, even to make a spelling correction, they
would need to submit a CLA.
We can be lenient about this: we don't require CLA signoff for casual
Max Pfingsthorn wrote:
Dear Cocoon Devs,
My Name is Max Pfingsthorn, I currently study for my Master of Science in
Artificial Intelligence at the University of Amsterdam, The Netherlands. You
can have a look at my CV (last updated Dec.2004) here:
Le 6 juin 05, à 14:06, Steven Noels a écrit :
...I think obtaining a CLA from proper document committers should be
enough for the mean time. Let's see where we get from here...
+1
Are you planning to have Daisy send changes emails like the wiki does?
It would be good to keep track of
Steven Noels wrote:
On 06 Jun 2005, at 12:39, Ross Gardler wrote:
In the above model a user is someone who self registered, can write
but not publish. A committer has the role doc-team and can publish.
I could configure the following setup:
* configure the site so that new document
Il giorno 06/giu/05, alle 14:22, Carsten Ziegeler ha scritto:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through which LogKit can be
configured as the logging system for Cocoon. The logging infrastructure
(LogEnabled) is not affected by
Carsten Ziegeler wrote:
So, please cast your votes on the following:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through which LogKit can be
configured as the logging system for Cocoon. The logging infrastructure
(LogEnabled) is not
On 06 Jun 2005, at 14:41, Bertrand Delacretaz wrote:
Le 6 juin 05, à 14:06, Steven Noels a écrit :
...I think obtaining a CLA from proper document committers should be
enough for the mean time. Let's see where we get from here...
+1
Are you planning to have Daisy send changes emails like
Daughter woke up early: done. Helma, can you cross-check?
Done. All looks fine. Updated the navigation tree on cocoondev.org and
the first page to reflect the new site.
Now all I need is my editor rights back.
Bye, Helma
Carsten Ziegeler wrote:
We recently discussed the famous logging topic [1] and it seems
that we agree to reduce the dependencies to LogKit.
So, please cast your votes on the following:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through
Carsten Ziegeler wrote:
...
We remove all direct dependencies to LogKit.
+1
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
On Jun 6, 2005, at 9:29 AM, Vadim Gritsenko wrote:
The only difference is the boot phase of Cocoon. We currently use
LogKit hardcoded there as well; this dependency will be removed. This
allows to run Cocoon without the logkit.jar.
Assuming boot phase uses servlet context logger; +1
+1
Carsten Ziegeler wrote:
We recently discussed the famous logging topic [1] and it seems
that we agree to reduce the dependencies to LogKit.
So, please cast your votes on the following:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through
Carsten Ziegeler wrote:
We recently discussed the famous logging topic [1] and it seems
that we agree to reduce the dependencies to LogKit.
So, please cast your votes on the following:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface
Vadim Gritsenko wrote:
Assuming boot phase uses servlet context logger;
Yes (in the case of the servlet env).
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Le 6 juin 05, à 14:22, Carsten Ziegeler a écrit :
...We remove all direct dependencies to LogKit..
+1
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
Hi,
I've just added a bugzilla entry for a new Cocoon-based site, as per
the instructions on the site.
Being a committer, I will proceed to fix and close the issue myself,
but I wanted to know if all that is needed is patching this [1] file or
is there something else that needs to be done?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35236.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
On 06 Jun 2005, at 14:32, Sylvain Wallez wrote:
We can consider that a CLA is needed for document committers as they
control official (i.e. published) docs,
+1
whereas document contributors are considered like people
contributing wiki pages and bugzilla patches, and implicitely accept
Bertrand Delacretaz wrote:
Le 6 juin 05, à 14:06, Steven Noels a écrit :
...I think obtaining a CLA from proper document committers should be
enough for the mean time. Let's see where we get from here...
+1
Are you planning to have Daisy send changes emails like the wiki does?
It would be
Hello Sylvain!
Thank you! Unfortunately, I didn't have the chance to do much with Multimedia
Information Retrieval yet. If you are interested, here is the website of the
research group concerned with this at my university:
http://www.science.uva.nl/research/isis/isisNS.html.
My personal
Steven Noels wrote:
On 06 Jun 2005, at 14:32, Sylvain Wallez wrote:
We can consider that a CLA is needed for document committers as
they control official (i.e. published) docs,
+1
whereas document contributors are considered like people
contributing wiki pages and bugzilla patches, and
Carsten Ziegeler wrote:
We recently discussed the famous logging topic [1] and it seems
that we agree to reduce the dependencies to LogKit.
So, please cast your votes on the following:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through
Nathaniel Alfred wrote:
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Instead of ? one could also use another character provided it is sufficiently
unlikely that the sequence curly-char appears in XSP-embedded content or where
XSP can be embedded (XSL). The special character should not be
We remove all direct dependencies to LogKit.
+1
On 06 Jun 2005, at 16:25, Sylvain Wallez wrote:
Regarding the modification, this can be a additional checkbox with a
validator requiring it to be checked, i.e. a user cannot register
without having clicked I accept.
OK. I tested this locally and will add this later to the live instance.
Carsten Ziegeler wrote:
We recently discussed the famous logging topic [1] and it seems
that we agree to reduce the dependencies to LogKit.
So, please cast your votes on the following:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through
In a second vote we will vote about the default logging system.
As a remark I'd like to add that just recently we deployed Cocoon in both Oracle Application Server
and Tomcat that were configured to use Log4J. But in neither case, it seemed possible to get the
Cocoon log messages (both cocoon
Jochen Kuhnle wrote:
I noticed that XSPMarkupLanguage.characters wraps text in
xsp:text elements. Is there a reason for this? At least my XSPs work
without this...
This logic has been there since beginnings of Cocoon2 XSP implementation [1]
(line 134), and I'd suggest leaving it there as
Ugo Cei wrote:
Hi,
I've just added a bugzilla entry for a new Cocoon-based site, as per
the instructions on the site.
Being a committer, I will proceed to fix and close the issue myself,
All [Link] bugs, right, not only this one? Thanks! :-)
but I wanted to know if all that is needed is
Geert Josten wrote:
In a second vote we will vote about the default logging system.
As a remark I'd like to add that just recently we deployed Cocoon in both
Oracle Application Server
and Tomcat that were configured to use Log4J. But in neither case, it seemed
possible to get the
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35242.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Vadim Gritsenko [EMAIL PROTECTED] wrote on 06.06.2005 16:28:19:
I think it is a bad idea to use exactly the same syntax as for
XSLT because it
makes really awkward to use XSP attribute interpolation inside
logicsheets.
You haven't written any XSLT producing Ant files recently, have you?
I guess you configured the Log4JLoggerManager in web.xml? What happened
then?
Carsten
To be honest: with the current settings nothing is being logged.. (nothing from
Cocoon at least) :-P
I tried several things, but nothing with the result I was looking for.
Currently I have the following
We have a project that needs to use a forms framework that is more
advanced than what SimpleForms provides. However, it is difficult on
selling cforms simply because they are marked unstable. What is it
going to take to mark it stable in 2.1.8? Can we simply identify the
known bugs in
On Lun, 6 de Junio de 2005, 7:22, Carsten Ziegeler dijo:
We remove all direct dependencies to LogKit. The logging will still use
the LoggerManager interface through which LogKit can be
configured as the logging system for Cocoon. The logging infrastructure
(LogEnabled) is not affected by the
On Lun, 6 de Junio de 2005, 8:37, Ugo Cei dijo:
Hi,
I've just added a bugzilla entry for a new Cocoon-based site, as per
the instructions on the site.
Being a committer, I will proceed to fix and close the issue myself,
but I wanted to know if all that is needed is patching this [1] file or
There has been a meeting of the ASF members this week, and some of its
results [1] are of particular interest to Cocoon:
- Upayavira and Torsten have been elected members of the ASF,
- Stefano has been reelected to the board.
Congrats to all, and a warm welcome to the new members!
Thanks
Niclas Hedhman wrote:
On Wednesday 01 June 2005 15:00, Ralph Goers wrote:
I'm also -1. I might consider replacing logkit with UGLI, but not LOG4J
directly. However, (a) UGLI is part of LOG4J 1.3 which is still alpha,
(b) an analysis needs to be done to determine how UGLI performs compared
to
Nice! But upto now there are only three of us (Reinhard,
you and me) and I'm wondering if we really need a room in that case.
But there are still two more months until the ApacheCon takes place,
so we can wait and see if more people are comming.
I'm sure that others will follow if we have
peter royal wrote:
On Jun 6, 2005, at 9:29 AM, Vadim Gritsenko wrote:
The only difference is the boot phase of Cocoon. We currently use
LogKit hardcoded there as well; this dependency will be removed. This
allows to run Cocoon without the logkit.jar.
Assuming boot phase uses servlet
Hi,
Is jdtcore.jar only used for compiling Java for XSP pages? I'm not using XSP
currently, so I am
wondering if I can just eliminate that jar file. It doesn't seem to affect
Cocoon. Can anyone confirm?
Thanks,
Geert
Geert Josten wrote:
Hi,
Is jdtcore.jar only used for compiling Java for XSP pages? I'm not using XSP
currently, so I am
wondering if I can just eliminate that jar file. It doesn't seem to affect
Cocoon. Can anyone confirm?
In trunk jdtcore.jar is only added if you enable the XSP block.
Ralph Goers wrote:
We have a project that needs to use a forms framework that is more
advanced than what SimpleForms provides. However, it is difficult on
selling cforms simply because they are marked unstable. What is it
going to take to mark it stable in 2.1.8? Can we simply identify the
71 matches
Mail list logo
