Antonio Gallardo wrote:
So, I'm pleased to propose Jorg Heymans, as a committer.
Please cast your votes:
+1, welcome Jörg!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
Antonio Gallardo wrote:
Hi folks,
Jorg Heymans has been around for more than 2 years now, and has
contributed with comments on the dev, help on the user list and
several patches along the way, [grep -i heymans status.xml] will
tell you more), all of good quality.
So, I'm pleased to propose
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=35813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Antonio Gallardo wrote:
Hi folks,
Jorg Heymans has been around for more than 2 years now, and has
contributed with comments on the dev, help on the user list and
several patches along the way, [grep -i heymans status.xml] will
tell you more), all of good quality.
So, I'm pleased to propose
Please cast your votes:
+1
--
Torsten
PGP.sig
Description: This is a digitally signed message part
Hi Robert,
Thanks for your analysis - I hope others are going to answer as well,
but here are at least my comments:
I've created several types and other proposed 'well-defined' bits
of
metadata to assist the publishing of these documents into a nice
format and easing the pain of parsing
Il giorno 31/lug/05, alle 14:01, Leszek Gawron ha scritto:
I have defined a custom type and convertor for that. The convertor is
actually managed by Spring and populated with a DAO and the
convertor's factory returns the Spring-managed instance instead of
creating a new one.
The convertor
(CCing Jeremias Maerki of FOP as I have discussed this with him
recently)
This is mostly a question for the PMC, but I see no need to discuss it
in private so here we go:
Other ASF projects have started to request CLAs [1] much earlier when
people contribute to their projects. The reason,
On Monday 01 August 2005 17:32, Bertrand Delacretaz wrote:
On the plus side: the CLA clearly defines the terms under which
intellectual property has been contributed to the ASF, quoting from
http://apache.org/licenses/#clas
The minus side: asking for a CLA even for small things (what's
On Mon, 1 Aug 2005, Bertrand Delacretaz wrote:
Other ASF projects have started to request CLAs [1] much earlier when
people contribute to their projects. The reason, IIUC, is to really
make sure that contributors understand what they're doing in terms of
licensing, copyright etc.
And this
On Mon, 1 Aug 2005, Niclas Hedhman wrote:
situation seems to be even worse, as the employer owns all output of the
employee (if they have any business claims in software, which nowadays are
Note that in this case the definition of a contribution and clause 5 help
you here. If your company
Bertrand Delacretaz wrote:
Thanks for your analysis - I hope others are going to answer as well,
I've forwarded Roberts original message to the Forrest list since we
will, no doubt, be using the output of this project. I've asked Forrest
devs to reply on our own list, but I will provide a
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]
Project cocoon has an issue affecting its community integration.
This issue affects 49
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]
Project cocoon has an issue affecting its community integration.
This issue affects 49
ok - my view was a more high-level one than classes and methods, which
are adequately covered by the javadocs. These are certainly useful
though, but see the proposed use-cases below for a more
component-oriented view.
Okay, this was something I wasn't sure about, but I thought it might
be
Hi all,
I have refactored the error handling stuff to have Cocoon stack traces,
i.e. a trace of the involved components and the corresponding locations
in the call stack.
For example, we can track nested JXTG macro calls, flowscript function
calls, pipeline locations, mounted sitemaps, etc.
[EMAIL PROTECTED] wrote:
Author: ugo
Date: Sat Jul 30 04:01:10 2005
New Revision: 226493
URL: http://svn.apache.org/viewcvs?rev=226493view=rev
Log:
Don't output div if there are no errors and give it a class attribute
Ugo,
Tags with an @id is an essential piece of the Ajax stuff, which
Robert Graham wrote:
Note that these assume a dynamic search of the refdoc index - I think
the full power of the refdoc will be available only when querying the
Lucene index directly, as is done in some of these use-cases, but the
document-oriented version (that will probably be published as
Le 1 août 05, à 15:29, Ross Gardler a écrit :
...The dynamic searching capability can be got for free by integrating
your work into Forrest ...
...Of course, Bertrand may have something else in mind as well.
I was thinking about searching on any metadata field provided by refodc
snippets.
Il giorno 01/ago/05, alle 15:24, Sylvain Wallez ha scritto:
Tags with an @id is an essential piece of the Ajax stuff, which is
based on partial updates of page areas found by their id.
Your update removes the @id on the enclosing tag, and removes the
placeholder that is necessary when no
Hi Robert,
...Maybe introducing an
order number metadata attribute would help and not be too hard to
manage? We could then rearrange the snippets be changing their order
numbers, while keeping the overall order based on the snippet types.
Perhaps. I think some sort of weight might give the
Ugo Cei wrote:
Il giorno 01/ago/05, alle 15:24, Sylvain Wallez ha scritto:
Tags with an @id is an essential piece of the Ajax stuff, which is
based on partial updates of page areas found by their id.
Your update removes the @id on the enclosing tag, and removes the
placeholder that is
Il giorno 01/ago/05, alle 15:57, Sylvain Wallez ha scritto:
If I'm not mistaken, that instruction copied the id attribute of
the fi:validation-errors element, but I've never put an id
attribute there. Is it necessary to set an id to every
fi:validation-errors element in order for it to
Ugo Cei wrote:
Il giorno 01/ago/05, alle 15:57, Sylvain Wallez ha scritto:
If I'm not mistaken, that instruction copied the id attribute of
the fi:validation-errors element, but I've never put an id
attribute there. Is it necessary to set an id to every
fi:validation-errors element in
Il giorno 01/ago/05, alle 16:38, Sylvain Wallez ha scritto:
Yes, sure. Where I'm lost is about knowing *what* produces this
fi:validation-errors element (it's not a widget, isn't it?). I never
used it, and a quick search did not revealed how it is produced.
It's not produced. You have to
Antonio Gallardo wrote:
So, I'm pleased to propose Jorg Heymans, as a committer.
Please cast your votes:
here's my +1! :-)
+1 here.. welcome!!
Tony
Sylvain Wallez wrote:
big-snip/
Conclusion
--
The Cocoon stacktrace gives some very valuable information about what
problem happened, and more importantly where it happened. We now need to
progressively add location information to important places in the code
to make these Cocoon
Il giorno 01/ago/05, alle 15:10, Sylvain Wallez ha scritto:
I have refactored the error handling stuff to have Cocoon stack
traces, i.e. a trace of the involved components and the corresponding
locations in the call stack.
I think it's time to take that hero plate out of the closet and
Hello devs,
I had a quick look on the Cocoon Portal.
I have a question about
http://cocoon.apache.org/2.1/developing/portal/portal-block.html#Create
+a+new+skin+for+your+portal
The current layout is table based which I need to change. I was looking
in the style producing matches and stylesheet.
Antonio Gallardo wrote:
Hi folks,
Jorg Heymans has been around for more than 2 years now, and has
contributed with comments on the dev, help on the user list and
several patches along the way, [grep -i heymans status.xml] will
tell you more), all of good quality.
So, I'm pleased to
Ugo Cei wrote:
Il giorno 01/ago/05, alle 15:10, Sylvain Wallez ha scritto:
I have refactored the error handling stuff to have Cocoon stack
traces, i.e. a trace of the involved components and the corresponding
locations in the call stack.
I think it's time to take that hero plate out of
Hi all,
Another important achievement in better error handlinn!
When an exception occurs in a pipeline after a TraxTransformer (i.e.
xslt), it now reports the *real* exception that was raised rather than a
useless RuntimeException (see [1] and search for 'new RuntimeException').
Also, the
Sylvain, you're the best. Working with portal block we were
*always* behind TraxTransformer, which was hiding all exceptions.
Now, we can manage to work more efficiently.
A big thank you!
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax :
Sylvain Wallez wrote:
Conclusion
--
The Cocoon stacktrace gives some very valuable information about what
problem happened, and more importantly where it happened. We now need to
progressively add location information to important places in the code
to make these Cocoon stacktraces
Tony Collen wrote:
Antonio Gallardo wrote:
So, I'm pleased to propose Jorg Heymans, as a committer.
Please cast your votes:
here's my +1! :-)
+1 here.. welcome!!
+1
--
Stefano.
Jean-Baptiste Quenot wrote:
Sylvain, you're the best. Working with portal block we were
*always* behind TraxTransformer, which was hiding all exceptions.
Now, we can manage to work more efficiently.
A big thank you!
Ditto from the Forrest community.
Ross
Antonio Gallardo wrote:
So, I'm pleased to propose Jorg Heymans, as a committer.
+1
Vadim
On Mon, 2005-08-01 at 16:38 +0200, Sylvain Wallez wrote:
? The fi:validation-errors element is described here:
http://cocoon.apache.org/2.1/userdocs/forms/xslt.html#fi%3Avalidation-
errors
Yes, sure. Where I'm lost is about knowing *what* produces this
fi:validation-errors element
On 7/31/05, Antonio Gallardo [EMAIL PROTECTED] wrote:
So, I'm pleased to propose Jorg Heymans, as a committer.
+1, and welcome aboard!
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at
On 01.08.2005 11:32, Bertrand Delacretaz wrote:
We have accepted several sizeable contributions without requiring a CLA
in the past, now the question is, do we want to follow the flow and ask
for CLAs for all contributions?
From my non-legal, but practical view: What are the ways we receive
Joerg Heinicke wrote:
On 01.08.2005 11:32, Bertrand Delacretaz wrote:
We have accepted several sizeable contributions without requiring a
CLA in the past, now the question is, do we want to follow the flow
and ask for CLAs for all contributions?
From my non-legal, but practical view: What
On Mon, 2005-08-01 at 13:19 -0600, Jason Johnston wrote:
You are correct, it is not produced by anything besides the template
author. It's simply a styling hint, much like fi:group, which is
handled entirely by the XSLT.
Unfortunately this means that it is never included in the AJAX
Antonio Gallardo wrote:
Hi folks,
Jorg Heymans has been around for more than 2 years now, and has
contributed with comments on the dev, help on the user list and
several patches along the way, [grep -i heymans status.xml] will
tell you more), all of good quality.
So, I'm pleased to propose
Will you commit to trunk as well?
salu2
On Mon, 2005-08-01 at 16:52 +, [EMAIL PROTECTED] wrote:
Author: sylvain
Date: Mon Aug 1 09:52:50 2005
New Revision: 226838
URL: http://svn.apache.org/viewcvs?rev=226838view=rev
Log:
Yeah! Real exceptions with Xalan rather than a useless
44 matches
Mail list logo