Just curious: what's the status of the SVN conversion?
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.net/weblogs/rael/
Carsten Ziegeler wrote:
Just curious: what's the status of the SVN conversion?
That is something that we are all wondering.
I just presumed that is was ready to go and got it like this:
svn co https://svn.apache.org/repos/asf/cocoon/trunk cocoon
--
David Crossley
Marcus Crafter wrote:
On Wed, 2004-07-28 at 14:15, Carsten Ziegeler wrote:
But let not implementation details (or technics) drive the syntax.
It is more important to have a good sitemap language than to have
a clean and small implementation.
I agree too mate.
Something that I'm wondering about
Hi,
I would like to discuss the design problem of the sitemap component. My plan is to
develop special let's call it transformer for transforming sources for pages written
or generated by analysts (model) to dynamic pages generating required results
(implementation). The form of model is custom
Ok, it seems that it works (=compiles), but I think it's not ready to go.
The svn:ignore properties are missing!
Carsten
-Original Message-
From: David Crossley [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 29, 2004 8:47 AM
To: Cocoon-Dev
Subject: Re: Status of SVN Conversion?
Hi,
I wrote a customer transformer, it works quite ok with cocoon2.1.4. Now I
updated cocoon to the latest version and I get these errors below, have you
changes anything? always when I want to create a new element calling the method
(startElement()) I get the error, can anybody help me
On 29 Jul 2004, at 09:19, Marc Portier wrote:
Rest assured I'm equally concerned with a number of other voices here
about (using Ugo's wording) 'giving just more rope to hang yourself
in'
However, when I see people 'removing and merging' then I can only see
less rope :-)
IMHO we need to be
Hi,
a transformer for 2.1.4 should work under 2.1.5 - I'm not
aware of any incompatible changes/problems in this area.
Can you show us your source code, this might give us a clue.
Carsten
-Original Message-
From: Halgurt Mustafa-Ali [mailto:[EMAIL PROTECTED]
Sent: Thursday, July
to jar basename: [cocoon-tests]
-DEBUG- Jar [cocoon-deprecated.jar] identifier set to jar basename:
[cocoon-deprecated]
-DEBUG- Dependency on avalon-framework exists, no need to add for property
avalonapi.jar.
-INFO- Made directory
[/usr/local/gump/public/workspace/cocoon-2.1/build/cocoon-20040729
X-Sieve: CMU Sieve 2.2
Delivered-To: [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
X-ASF-Spam-Status: No,
-Original Message-
From: Halgurt Mustafa-Ali [mailto:[EMAIL PROTECTED]
Hi,
Thanks for replying. Please see the Attachment for the code
and the error message.
Ok, I guess the problem lies in this line:
super.startElement (, result, result, null);
You have to pass an
Hi,
Thank you very much, I will try that and tell you if it works.
Best regards,
Halgurt
X-Sieve: CMU Sieve 2.2
Delivered-To: [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post:
Sorry, we were in the middle of switching to use SVN.
Patches applied now to depend logging-log4j and to
enable Gump to use our new SVN trunk.
I knew that was occurring, I wasn't thinking, sorry. Thanks for working on
it, and getting this done.
Now you are using SVN with it's built in 'simple
Carsten Ziegeler wrote:
Ok, it seems that it works (=compiles), but I think it's not ready to go.
Sorry, guys - forgot to post status :-)
Cocoon 2.2-dev is here:
http://svn.apache.org/repos/asf/cocoon/trunk/
Cocoon 2.1.6-dev is here:
David Crossley wrote:
Miles Elam wrote:
snip excellent explanation/
Thanks Miles, you eloquently said everything
that i wanted to say.
Miles, thank you too! I couldn't say it better!
--
Reinhard
Conal Tuohy [EMAIL PROTECTED] writes:
Peter Hunsberger wrote:
As others have said, one needs to step back and look at the overall
objective: what do you want Cocoon to do when you feed it a request
(either via http or CLI or whatever)? Figure out all the
high level
use cases and
DURDINA Michal [EMAIL PROTECTED] writes:
Hi,
I would like to discuss the design problem of the sitemap
component. My plan is to develop special let's call it
transformer for transforming sources for pages written or
generated by analysts (model) to dynamic pages generating
required
Steven Noels wrote:
On 29 Jul 2004, at 09:19, Marc Portier wrote:
Rest assured I'm equally concerned with a number of other voices here
about (using Ugo's wording) 'giving just more rope to hang yourself in'
However, when I see people 'removing and merging' then I can only see
less rope :-)
Adam R. B. Jack wrote:
Sorry, we were in the middle of switching to use SVN.
Patches applied now to depend logging-log4j and to
enable Gump to use our new SVN trunk.
I knew that was occurring, I wasn't thinking, sorry. Thanks for working on
it, and getting this done.
Now you are using SVN with
On 29 Jul 2004, at 19:34, Stefano Mazzocchi wrote:
A little bit of history is needed:
Thanks for your recount of my lurking years. :-)
Now, for those who were not there at that time: Ovidiu's proposal was
*NOT* accepted happily. For the most part, it was not understood until
several months
I've been a strong believer in 'internal innovation', which means to
give room for people to experiment.
We have now migrated onto SVN, which unlike CVS, has a great deal of
support for moving things around and merging different parts of the tree
together.
My proposal is to create a private
Steven Noels wrote:
snip;
IMHO, simplicity has to do with predictability. XML grammars have this,
scripting languages don't. While the use of a non-XML (scripting?)
grammar for the site/flowmap might be clever, it might reduce the
predictability. Too much magic for my poor brains. And even XML
On 29 Jul 2004, at 20:40, Tony Collen wrote:
Steven Noels wrote:
snip;
IMHO, simplicity has to do with predictability. XML grammars have
this, scripting languages don't. While the use of a non-XML
(scripting?) grammar for the site/flowmap might be clever, it might
reduce the predictability. Too
I'll change that. And, I see that the cocoon repository (as metadata has
it
in Gump) is still marked as CVS, not SVN. I'll change that also..
BTW: It seems to have worked:
http://brutus.apache.org/gump/public/cocoon-2.1/gump_work/update_cocoon-2.1.html
Although it seems there may still be
On 29 Jul 2004, at 20:20, Stefano Mazzocchi wrote:
My proposal is to create a private branch for every committer that
wants it and place it in
http://svn.apache.org/repos/asf/cocoon/private/[id]
Thoughts?
I know I'm at the verge of becoming a traditionalist, but IMHO we
should never create
Steven Noels wrote:
On 29 Jul 2004, at 20:20, Stefano Mazzocchi wrote:
My proposal is to create a private branch for every committer that
wants it and place it in
http://svn.apache.org/repos/asf/cocoon/private/[id]
Thoughts?
I know I'm at the verge of becoming a traditionalist, but IMHO we
Title: Message
Has there been any discussion
of extracting Java continuations into a
standaloneproject?
There are a lot of people
(judging by web searches... and including me :-) who would love to use
this functionality, but not in the context of Cocoon.
Ugo Cei wrote:
Dear Cocooners,
while working on Butterfly, I started looking at the TreeProcessor and
I was astonished at the number of classes I have to port, if I want to
reimplement it:
o.a.c.components.treeprocessor: 26 classes
o.a.c.components.treeprocessor.sitemap: 44 classes
Reinhard Poetz wrote:
David Crossley wrote:
Miles Elam wrote:
snip excellent explanation/
Thanks Miles, you eloquently said everything that i wanted to say.
Miles, thank you too! I couldn't say it better!
+1 !
Sylvain
--
Sylvain Wallez Anyware Technologies
Stefano Mazzocchi wrote:
I've been a strong believer in 'internal innovation', which means to
give room for people to experiment.
We have now migrated onto SVN, which unlike CVS, has a great deal of
support for moving things around and merging different parts of the
tree together.
My proposal
I'm still in skimming mode, but I'll lob a nearly incoherent thought
in from the sidelines...
On Thu, 29 Jul 2004 10:34:29 -0700, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
...
A little bit of history is needed:
- at the beginning there was no sitemap. all the pipeline machinery was
Geoff Howard wrote:
Why insert this stream of consiousness into this discussion? I have a
gut feeling that something in this discussion could lead to a solution
along these or totally new lines that cures this uneasiness, or
could make it even worse.
I feel the same way: sitemap and flowscript
Steven Noels wrote:
On 29 Jul 2004, at 20:40, Tony Collen wrote:
Scripting languages (and programming languages in general) are easy to
create, all you need to do is define the grammar and tokens, and feed
it all to something like JFlex/BYacc to create a parser. Perhaps it's
easier said than
What about playground? Works for us over here, and give people
somewhere to throw their toys ;)
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Friday, 30 July 2004 1:58 p.m.
To: [EMAIL PROTECTED]
Subject: Re: [proposal] Private Branches
Stefano Mazzocchi
Tony Collen dijo:
Steven Noels wrote:
On 29 Jul 2004, at 20:40, Tony Collen wrote:
Scripting languages (and programming languages in general) are easy to
create, all you need to do is define the grammar and tokens, and feed
it all to something like JFlex/BYacc to create a parser. Perhaps
Stefano Mazzocchi dijo:
And let's keep in mind that groovy is not even release final (I talked
to James Strachan yesterday about this.. and he's obviously very excited
and told me a way to implement continuations in groovy once macros are
built into the language... which is due in the near
36 matches
Mail list logo
