Carsten Ziegeler wrote:
So, in the end, a mixture is imho the right way.
Amen: commit then review is way faster than the other way around.
Balanced Meritocratic Do-ocracy is our government model and it really
works well.
Some of us (myself first) come out rather strong sometimes, due to our
Sylvain Wallez wrote:
Niclas Hedhman wrote:
End of the day, Carsten does what he likes.
Sure he does what he likes. But please allow me to raise what I consider
as a potential community issue.
Fortunately, Carsten's answer shows that he understood my concerns,
which is good.
And I also know
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
...
So, again: everyone is invited to join the party. Open Source is
either driven by itch scratching (well, not always, but that's not
important here), so if it itches, do something about it, that's all I
can say.
+1
I'll also like to add that
Torsten Curdt wrote:
Ok, folks. I've added a ReloadingClassloader
to jci which we could use for Cocoon. It
reloads classes from a specific repository.
YEY!
Now the idea is to point it to the Eclipse
output directory so once you compiled your
classes in eclipse they would be available
to Cocoon
Wojciech Gdela wrote:
Hello,
But maybe an interesting question would be: how would cocoon be
different when
written in another language. Would you need an XML sitemap if you
could just
write your sitemap in a dynamic language?
I've recently developed very small cocoon-like framework in php
On Tue, 22 Feb 2005 17:00:19 +0100, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Wojciech Gdela wrote:
Hello,
sniOO pipeline discussion (sorta)/snip
It's also true that we know a lot more than pipeline caching is more a
myth than a real useful thing, at times and more so in complex web
this might be useful, it might not be. But personally I'd like to be
able to store the mappings information in something like the
cocoon.xconf in an xml format, it could be the struts/jsf/spring
talking but having the servlet configuration in one place makes sense
(to me, there could be good
Ok, folks. I've added a ReloadingClassloader
to jci which we could use for Cocoon. It
reloads classes from a specific repository.
Now the idea is to point it to the Eclipse
output directory so once you compiled your
classes in eclipse they would be available
to Cocoon right away.
...still we have
Hello,
But maybe an interesting question would be: how would cocoon be different when
written in another language. Would you need an XML sitemap if you could just
write your sitemap in a dynamic language?
I've recently developed very small cocoon-like framework in php
language. What I really love
Sylvain Wallez wrote:
SNIP/
You have some relevant and also true points in your statements, no
doubt. But have a look at how new things really came into our project,
there often were some nice emals like He, I implemented this cool
feature, now we can... - and these weren't always mine.
So, in
Oh my, I'm in this os scene for so many years now and sure: I know the
problems and the potential dangers. But of course there is also the
danger of death by discussion! And please, just take some minutes and
think about all the commits made to Cocoon - you'll find many examples
where things
Carsten Ziegeler wrote:
...
So, again: everyone is invited to join the party. Open Source is either
driven by itch scratching (well, not always, but that's not important
here), so if it itches, do something about it, that's all I can say.
+1
I'll also like to add that committers should learn to
Carsten Ziegeler wrote:
snip/
So, my opinion is we should just look at what people want to use, what
*we* thing is the best to have, combine those two and then: just do
it. The past showed that first discussing things lead to no code while
first coding somethings and then start a discussion
On Sunday 20 February 2005 04:58, Sylvain Wallez wrote:
But if I have to discuss each and every feature with 20 people -
everyone having it's own ideas - I'm most times blocked: 5 people like
the idea, 3 people don't like the idea and so you're doomed.
I strongly disagree with your point
Greg Weinger wrote:
This may be way off course, but have you thought about a Cocoon in
Squeak?
No and I'm *NOT* rewriting 4 million lines of code (cocoon + all the
libraries it depends on!) in another language, thanks.
--
Stefano.
Bart Molenkamp wrote:
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 16, 2005 3:14 PM
To: dev@cocoon.apache.org
Subject: Re: [RT] How scripting made me hate java
Big -1
Not knowing where the code is is bad, having to versions that claim
quoting Stefano Mazzocchi [EMAIL PROTECTED]:
Greg Weinger wrote:
This may be way off course, but have you thought about a Cocoon in
Squeak?
The thought must have crossed a lot of minds - but I don't actually know of
success-stories of the
Rogier Peters wrote:
But maybe an interesting question would be: how would cocoon be different when
written in another language. Would you need an XML sitemap if you could just
write your sitemap in a dynamic language?
Yes, that is a very interesting question, but it's not something I want
to
Stefano Mazzocchi wrote:
...
This is why I think we should make an effort to think about how we can
solve this time/cognitive-energy discrepancy between the scripting and
the java try/fail cycle.
+1
In fact, for users, xslt in Cocoon is cool because you get instant
feedback, and the current
Il giorno 16/feb/05, alle 00:32, Stefano Mazzocchi ha scritto:
You can test the input and output of a pipeline, but this is exactly
what I do with my browser when I hit it! Sure I can automate that when
it's ready to know what is broken or not later on, but it's not unit
testing, is functional
Ralph Goers wrote:
2. I really want thread-safe generators and transformers.
I've glanced at the sitemap code to see what it would take to do item 2
and it didn't seem to me that the code was pretty understandable.
Just so you know, this is already done and implemented.
Remind me to commit
Vadim Gritsenko wrote:
Ralph Goers wrote:
2. I really want thread-safe generators and transformers.
I've glanced at the sitemap code to see what it would take to do item
2 and it didn't seem to me that the code was pretty understandable.
Just so you know, this is already done and implemented.
Ralph Goers wrote:
Vadim Gritsenko wrote:
Ralph Goers wrote:
2. I really want thread-safe generators and transformers.
I've glanced at the sitemap code to see what it would take to do item
2 and it didn't seem to me that the code was pretty understandable.
Just so you know, this is already done
Vadim Gritsenko wrote:
[1] http://marc.theaimsgroup.com/?t=10958635923r=1
Yeah, this is where I got the idea. Scanning trunk, it doesn't look
like you've actually checked anything in? However, I don't believe the
technique you proposed will always work. The problem is, some
generators
Vadim Gritsenko wrote:
Have I mentioned that this is for C2.2 only? :-)
Vadim
[1] http://marc.theaimsgroup.com/?t=10958635923r=1
Forget my previous comment. I don't know what I was thinking. Your
technique works just fine.
Ralph
Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations
are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and SourceResolver, Store,
XML
Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and SourceResolver, Store, XML
utils,
SNIP/
I agree with most points from Stefano and we see it each time we do
Cocoon training that it's very hard for new users to start with Cocoon.
Imho that's a main difference between Cocoon and other projects: with
other projects it's very easy to start, but you might get stuck later on
in
Sorry Stefano, but I feel that you are somewhat biased. :-) I'm not
saying unit tests are the solution to all evil, and I certainly
understand that within the *current* Cocoon environment unit tests
might not help much. But this is because the current codebase isn't
test-friendly, so that it
Torsten Curdt wrote:
I think there is another explanation why there
are so little changes: We are way more concerned
about the stability of contracts. ...even for trunk!
Quite a few people now have live installations
and seem to go for the na, don't change it!
it ain't really broken. This seems
As someone who's walked into a cocoon project over the last few weeks,
I don't have a problem with the usage pattern as such (sitemap.xconf,
flowscripts, cforms etc). Most of the problems I've had have been to
do with some of the crack-induced choices made by other parties (I
wont go into
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
IMO our huge community problem is what is most important. No, I'm
certainly not talking about our excelent existing community, I'm
talking about the fact that we only elected two new committers during
2004, compare that to around ten during
Torsten Curdt wrote:
Yepp ...yepp ...yepp
Guys, maybe we should get together
more often. I found this always
very helpful...
I'm up for it. And ask for some corporate sponsorship for those in far
and distant lands. A two day hackathon somewhere in Europe. I like the idea.
Regards, Upayavira
On Wednesday 16 February 2005 15:41, Reinhard Poetz wrote:
Niclas Hedhman wrote:
Why not use SVN's more exotic features of external linking, and plainly
include the Excalibur codebase (source that is) as part of Cocoon? You
all have commit access to it, and it is not likely that the
Upayavira wrote:
Torsten Curdt wrote:
Yepp ...yepp ...yepp
Guys, maybe we should get together
more often. I found this always
very helpful...
I'm up for it. And ask for some corporate sponsorship for those in far
and distant lands. A two day hackathon somewhere in Europe. I like the
idea.
If
Il giorno 16/feb/05, alle 13:01, Carsten Ziegeler ha scritto:
If we can't do it earlier, we could use the ApacheCon in Stuttgart
this year. We could meet the days before or after the conference, so
this would reduce travel costs.
+1
Ugo
--
Ugo Cei - http://agylen.com/blojsom/blog/
Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and SourceResolver, Store, XML
utils,
Bart Molenkamp wrote:
Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations
are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and
Reinhard Poetz wrote:
Why not use SVN's more exotic features of external linking, and
plainly include the Excalibur codebase (source that is) as part of
Cocoon? You all have commit access to it, and it is not likely that
the Excalibur community will make any big changes in the future, and
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 16, 2005 3:14 PM
To: dev@cocoon.apache.org
Subject: Re: [RT] How scripting made me hate java
Big -1
Not knowing where the code is is bad, having to versions that claim
This may be way off course, but have you thought about a Cocoon in
Squeak? That perhaps Java won't ever be able to give you the rapid
development experience (with easy manipulation of the core engine--the
damn virtual machine, if you're crazy) you're looking for?
Alan Kay came to this
Daniel Fagerstrom wrote:
IMO our huge community problem is what is most important. No, I'm
certainly not talking about our excelent existing community, I'm talking
about the fact that we only elected two new committers during 2004,
compare that to around ten during 2003, and probably similar
Stefano Mazzocchi wrote:
snip
And I suspect a lot can be done by just documenting how existing
cocoon committers do their development today, not *on-top-of* cocoon,
but *within* cocoon.
Stefano,
Your post reminds me a little bit of the architecture of the computers
we use. Back when I was a
And now you ask me to write java code and take 60 seconds to see if
anything I changed made a difference?
You gotta be kidding.
It's a pain ...I know.
Another private conversation tried to convince Torsten of moving the
compiling classloader into the pipeline system so that we could use
pipeline
Il giorno 15/feb/05, alle 17:37, Stefano Mazzocchi ha scritto:
sniplots of interesting things which I'll need to digest before
venting my thoughts/snip
plus this...
When I think about implementing real blocks, I think about the *weeks*
of not having anything visible and I never even start!!
On Tue, 15 Feb 2005 11:37:18 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Obviously, it doesn't the stacktrace is a million lines long... most
of this code I don't recognize anymore, it's like looking at somebody
else's project now and it's big and massive. And the logs were all
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
IMO our huge community problem is what is most important. No, I'm
certainly not talking about our excelent existing community, I'm
talking about the fact that we only elected two new committers during
2004, compare that to around ten during
Gianugo Rabellino wrote:
On Tue, 15 Feb 2005 11:37:18 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
Obviously, it doesn't the stacktrace is a million lines long... most
of this code I don't recognize anymore, it's like looking at somebody
else's project now and it's big and massive. And
Damn, hit send too soon :-)
Stefano Mazzocchi wrote:
People keep talking about documentation but let's get real: we know
that the code is the place to look, you can 'control-click' in eclipse
on a method and see what it does, you don't need documentation if you
are a cocoon committer to
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
IMO our huge community problem is what is most important. No, I'm
certainly not talking about our excelent existing community, I'm
talking about the fact that we only elected two new committers during
2004, compare that to
Stefano Mazzocchi wrote:
No, and I don't care.
This is *NOT* what I'm trying to solve. I don't care if users user
java or not, what I care is that cocoon committers are not afraid of
the core or that they are not adding java components to the system
because writing them in javascript is faster
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and SourceResolver, Store, XML
utils, etc. Only the
Sylvain Wallez wrote:
So one big problem again here is documentation. Not user-level docs that
has been identified as a problem for long an which is currently
considered seriously thanks to Reinhard, but developer-level
documentation. We can reasonably suspect that many potential developers
Niclas Hedhman wrote:
On Wednesday 16 February 2005 07:06, Sylvain Wallez wrote:
Something that doesn't help also is the fact that our foundations are
maintained and documented (or not) elsewhere, at Excalibur. This
includes the Avalon framework interfaces and SourceResolver, Store, XML
utils,
54 matches
Mail list logo
