Le 27 mai 05, à 03:24, Antonio Gallardo a écrit :
...If I becomes the root of our zone,
then I will be glad to provide all the necessary support to materialize
this effort...
Great, thanks!
I've not used solaris yet but I've worked with many different unixes,
if you can give me access I
1- Current released version
2- Daily SVN 2.1.x
3- Daily SVN 2.2.x..
Good idea, but I'm not sure if we want to have three versions there,
maybe we should start with the release and go from there?
YES! YES! YES!
I mean: good idea to start with the current released version and go from
Le 27 mai 05, à 09:43, Linden H van der ((MI)) a écrit :
...Just a thought: since much of the samples allow data entry, you'll
quickly get to the point where the rubbish hides the usefulness. Add a
cron job of some kind that replaces the build with a fresh one on a
regular basis (once a day or a
Nathaniel Alfred wrote:
-Original Message-
From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 26. Mai 2005 15:42
To: dev@cocoon.apache.org
Subject: Re: [RT] Block usage
a block deployer block
Basically the block deployer will be a stand-alone
Leszek Gawron wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Reinhard Poetz wrote:
snip/
It's a pity we cannot move .xconf files into jars.
Why can't we?
AFAIR due to the fact that resource:/ protocol is not as functional as
file:/ (no directiories?)
Leszek Gawron wrote:
Reinhard Poetz wrote:
... but there needs some work to enable the blocks:/ protocol,
component management and block-aware flowscript (e.g.
cocoon.blocks.blockA.myFunc())
There is a block:/ protocol in OSGi. I haven't read OSGi specification
though - I saw it in
Bertrand Delacretaz wrote:
Le 27 mai 05, à 03:24, Antonio Gallardo a écrit :
...If I becomes the root of our zone,
then I will be glad to provide all the necessary support to materialize
this effort...
Great, thanks!
+1 :)
I've not used solaris yet but I've worked with many different
Hi
On 26 May 2005, at 14:42, Stefano Mazzocchi wrote:
Do you see a point where they'll be
able to put together semi-complex webapps in LEGO style?
Dude, can you read?
http://cocoon.apache.org/ [very first paragraph]
Patently I cannot ;-)
[nobody is responding because that's like asking:
Le 27 mai 05, à 11:10, Daniel Fagerstrom a écrit :
...Having all three would be nice. If I had to chose one I would start
with trunk. That will give it some stress testing and make it mature
faster. Also it will make us *very* motivated to fix bugs ;)...
Once we have one instance going with
Hi,
assuming I am about to put a Cocoon webapp behind an Apache 2.0 server
with mod_proxy as explained in the Wiki, what do I lose by using the
lite Jetty version distributed with Cocoon as opposed to the full
version?
Consider that authentication, crypto, virtual hosting, compression,
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
AFAIR due to the fact that resource:/ protocol is not as functional
as file:/ (no directiories?) and it would be quite intensive
operation to find .xconf files.
Carsten made the resource: protocol traversable a couple of months ago.
Nope,
Hello Daniel,
Thanks for your extremely edifying response. As with Stefano, will it
be ok to cite some of your comments in this report? I may not cite you
literally, but I need to credit you if I do. Would that be ok?
The report will be published on Techwatch:
Some time ago we decided that we want a flat directory structure
(/cocoon/blocks/[block-name]/... instead of
/cocoon/blocks/[community-status]/[block-name]/...) for blocks but we haven't
yet changed it.
I will do the move on Monday - please make sure that you have checked in all
your
David Casal wrote:
6. The new block contain some new and intersting stuff that is not
available before. After a number of refactorings it consists of a
number of blocks that are reusable and solves well defined concerns.
Now the user puts the blocks in a new project in Sourceforge (or
On May 25, 2005, at 8:49 AM, Linden H van der (MI) wrote:
Well, since there are no rules for documentation right now, everyone
wanting to write documentation is free to use whatever tool they like.
Sorry, but I haven't seen (apart from Upayavira and Ralph) anyone
posting here's some
On May 26, 2005, at 1:00 PM, Ross Gardler wrote:
Glen Ezkovich wrote:
Since documentation is best gathered in a CMS, because there
will likely
(hopefully) be more than one person working on it, this
inevitably means
that everyone should use THAT CMS to avoid scattering
documentation
On May 26, 2005, at 3:05 PM, Linden H van der (MI) wrote:
Glen and Ross,
Before duplicating my thoughts in similar replies I want to state this
(replies in random order):
I work in a university department, doing research, so I'm fully aware
what it takes to go through the process of putting
On 27 May 2005, at 03:24, Antonio Gallardo wrote:
I believe, I am reading this mail with a time delay. What is clear to
me
is that I don't received a root password of the cocoon Solaris zone.
And I
don't know if the zone is already up. If I becomes the root of our
zone,
then I will be glad
Glen Ezkovich wrote:
...
I'm tired of the discussion about tool vs. people. We need people to
write docs, we need tools to help them write docs.
It is not an either or argument, why are people so polarised?
I don't think we're polarized. I just think we each emphasis different
Le 27 mai 05, à 14:47, Steven Noels a écrit :
...People interested in co-administering Daisy (users, creation of
variants, ACL rules, sites): please stand up...
I haven't used Daisy seriously yet, but if it's small things here and
there you can count me in.
-Bertrand
smime.p7s
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=35094.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Nathaniel Alfred [EMAIL PROTECTED] wrote on 26.05.2005
16:34:13:
I think I was too terse to make myself understand. With in-text
replacement
I meant
h1Hello {username}/h1
as shortcut for
h1Hello xsp:exprusername/xsp:expr/h1
I am against that because it risks to break
Le 27 mai 05, à 14:47, Steven Noels a écrit :
...People interested in co-administering Daisy (users, creation of
variants, ACL rules, sites): please stand up...
My coworker and local Daisy expert, Patrick Ahles, agrees with helping out in
user-administration provided it requires a limited
Bertrand Delacretaz wrote:
Le 27 mai 05, à 14:47, Steven Noels a écrit :
...People interested in co-administering Daisy (users, creation of
variants, ACL rules, sites): please stand up...
I haven't used Daisy seriously yet, but if it's small things here and
there you can count me in.
I'm
Mark Leicester wrote:
Whoops, way too fast. If you are interested in coming along, please add
your name here:
http://wiki.apache.org/cocoon/CocoonUserGroupLondon
Hello everyone,
I'd like to invite Cocooners who will be in the London area on the
evening of Wednesday June 15th, 2005 to an
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=35094.
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=30432.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
David Casal wrote:
That's what I'm after. So you see a roadmap whereby first you work on
easy kernel installation -then- play semantics.
Correct. The other way around would make the goal even harder to
bootstrap. No advancement in an open source software happens if you
don't capture some
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!
Sylvain
Hi,
the EclipseJavaCompiler chokes on warnings, resulting in the XSP not
working. This is because in line 365 (cocoon-2.1.8-dev), it checks against
result.hasProblems() instead of result.hasErrors(). I'd like to
propose an option so the compiler ignores warnings and fails only if there
are
On Vie, 27 de Mayo de 2005, 15:47, [EMAIL PROTECTED] dijo:
Author: vgritsenko
Date: Fri May 27 13:47:38 2005
New Revision: 178819
URL: http://svn.apache.org/viewcvs?rev=178819view=rev
Log:
add xalan / xerces version info
Is change this saxon compatible?
Best Regards,
Antonio Gallardo.
On 27.05.2005 16:05, [EMAIL PROTECTED] wrote:
Author: antonio
Date: Fri May 27 07:05:02 2005
New Revision: 178778
URL: http://svn.apache.org/viewcvs?rev=178778view=rev
Log:
Cforms block: Improved dynamic selection list performance inside repeaters.
Sorry, but I absolutely don't like it for
Hi Joerg:
I am glad to see you active on the list again. As I told you in GT2004, I
like your radar over my work. :-)
[comments below]
On Vie, 27 de Mayo de 2005, 19:02, Joerg Heinicke dijo:
On 27.05.2005 16:05, [EMAIL PROTECTED] wrote:
Author: antonio
Date: Fri May 27 07:05:02 2005
New
33 matches
Mail list logo
