a CVS question now :)
if I incorrectly checked it a text file as binary (well, I didn't, it's
eclipse that transparently does it until you find out and fix it! grrr)
how do i change it back to text?
TIA
Stefano.
J.D. Daniels wrote:
Cocoon is not an app.
It is a framework.
Amen!
And our users are not idiots, but experienced web programmers.
Let's treat them as such.
Stefano.
[EMAIL PROTECTED] wrote:
crafterm2003/03/25 08:44:31
Modified:src/documentation/xdocs/userdocs/flow
invalidContinuation.xml
Log:
* Fixing build (file fails validation)
ok, damn, forgot to remove that sorry.
Stefano.
David Crossley wrote:
I propose Andrew Savory as Cocoon committer. He has been
involved with Cocoon since mid-2000 and more intensely during
the past year. Browsing the email archives i see plenty of
discussion, bug reports, testing, and suggestions. This indicates
his commitment. Andrew is also
[EMAIL PROTECTED] wrote:
excalibur-event also depends on it, so I think this should be part of the
core ?
Uh, really? damn. thanks for spotting that.
I'll revert the changes ASAP.
Stefano.
David Crossley wrote:
I propose Geoff Howard as Cocoon committer. He has been
involved with Cocoon for the past year, providing lots of
useful discussion and bug report/fixing. He has submitted
many useful patches, for example with the file upload.
He gives tremendous assistance on cocoon-users,
.
The more you can find costructive critics to what we are doing, the more
you are helping us to help you and help ourselves doing so.
Stefano.
Niclas Hedhman wrote:
On Monday 24 March 2003 02:08, Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 23/03/2003 15.25:
What do you think?
+1 for the source distro.
I agree, except...
As for the binary distro, we simply never did one really. What I'd like
to see is
cocoon-full.war
and it
might well be potentially harmful for the perception of two different
groups, one that does code and one that does docs. Perception that has
been harming the documentation process a lot.
Stefano.
Bertrand Delacretaz wrote:
Le Dimanche, 23 mars 2003, à 15:25 Europe/Zurich, Stefano Mazzocchi a
écrit :
...
Before you jump up and down and scream no, no, binaries are easier
for our users, get off your
life-without-a-compiler-windows-inflicted-mindset and think that every
JDK comes
) easier release process (will make it easier for having multiple
release coordinators, hopefully helping producing a faster release cycle)
Thoughts?
Stefano.
and let's admit it: a binary installation won't make it any
easier for joe-user to understand a sitemap anyway.
Stefano.
:/
Stefano.
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 24/03/2003 11.53:
...
1) bandwidth reduction (yes, this should be our concern as cocoon is
getting so big)
Then start taking ant away from CVS and distros,
This is coming up next! :)
and use a mirrored
download for the jars, it's part
.
Stefano.
and wars help in the very short term,
but harm in the middle term.
Stefano.
little GUI skills and no
experience with jnlp, I'd be willing to help work on that.
I think this is YAGNI.
I say: let's start incrementally: we build one well-done build.sh-driven
distro and see what is the user reaction. *then* move from there.
What do you think?
Stefano.
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 24/03/2003 12.21:
Nicola Ken Barozzi wrote:
...
I'm sure that if we don't give our users a sample precompiled version
it will have a really negative impact on the alpha-view of Cocoon and
stop many from checking it out, whatever technical
very cool but
too hard to 'tune down' to simpler needs?
I'm asking because I'm starting to wonder if this is the case.
puzzled/
Stefano.
Steven Noels wrote:
On 24/03/2003 14:23 Stefano Mazzocchi wrote:
I don't expect 2.0 to live long after 2.1 is out. There is no reason to.
To be really honest, I'd like to see some facts backing this statement.
Not technical facts, but truly compelling reasons to make the switch. If
people
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Yes. This is going to be even more with the introduction of the flow
since people with client-side knowledge (html + css + javascript + xml
+ namespace + xslt) will be able to write full-blown web applications
with database connectivity *without
Steven Noels wrote:
On 24/03/2003 15:28 Stefano Mazzocchi wrote:
I for one think the 'copy cocoon.war into webapps dir and look at
http://server:port/cocoon/' paradigm helps a lot of newcoming users
up running very fast.
please, define 'be up and running'.
Not knowing about javac, ant
Stephan Michels wrote:
On Mon, 24 Mar 2003, Stefano Mazzocchi wrote:
Stephan Michels wrote:
And then PURITY.txt?
This is my try to get people into cleaning up their mess.
It is the dump of the cut/paste discovery tool. Since it normally takes
5/6 hours to do a normal cut/paste discovery
that others reconsider their vote.
Stefano.
Stephan Michels wrote:
On Sun, 23 Mar 2003, Stefano Mazzocchi wrote:
As I think most of the people here knows, Forrest is a Cocoon spin-off
project that focuses on static-snapshots of publishing-intensive web
sites with complex needs.
Cocoon now self-generates its own static website, but given
be wy cool :)
or even using antdoc which is pretty neat.
But please don't commit hand-drawn diagrams or they'll do more harm than
good later on.
Stefano.
context=code assigned-to=open
Move complete Source implementation to Excalibur.
/action
why do we have both todo.xml/changes.xml *and* status.xml?
Stefano.
Stefan Bodewig wrote:
Hi,
there is a name clash between the concurrent projects defined in
projects/dougLea.xml in Gump's CVS module and the one defined in
http://cvs.apache.org/viewcvs/~checkout~/cocoon-2.1/gump.xml.
I have no idea what this thing inside Cocoon is about, but please
rename the
.
Thanks for your feedbac.
Stefano.
Stefan Bodewig wrote:
On Sun, 23 Mar 2003, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
All right. I think I found out the problem: it seems that the gump
descriptor for jakarta-slide is incorrect and doesn't expose all the
jars that we need and we depend on.
I've looked into it.
Cocoon's
Stefan Bodewig wrote:
On Sun, 23 Mar 2003, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
All right. I think I found out the problem: it seems that the gump
descriptor for jakarta-slide is incorrect and doesn't expose all the
jars that we need and we depend on.
Quite possible. Slide used
Stephan Michels wrote:
On Mon, 24 Mar 2003, Stefano Mazzocchi wrote:
Stefan Bodewig wrote:
On Sun, 23 Mar 2003, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
All right. I think I found out the problem: it seems that the gump
descriptor for jakarta-slide is incorrect and doesn't expose all
(given the fact users just want docs,
not necessarily the latest-greatest code which produces such docs).
All right, I think we need a vote on this. Please see next email.
Stefano.
a 'fast-yet-potentially-disruptive' move rather
than a 'slow-yet-carefully-planned-not-to-disrupt-anything' one.
I vote +1 to all three. And I also volunteer to help.
Please, place your vote.
Stefano.
.
What do you think?
Stefano.
descriptor for jakarta-slide is incorrect and doesn't expose all the
jars that we need and we depend on.
gump-folks, can you please confirm? Thank you.
Stefano.
thinking at those pipeline-wide problems with little
aspect orientation in mind.
Stefano.
comes up great :)
[and those of you who experienced my cooking know what I'm talking about :)]
Stefano.
Steven Noels wrote:
I guess so. We, the doco people, also have the right to do disruptive
things! ;-)
There is no such things as 'doco people', Steven. I got already busted
once for that ;-)
Stefano.
J.Pietschmann wrote:
Santiago Gala wrote:
Nagging FOP developers to deprecate those classes but keep an
implementation in term of the new ones at least during one full
development/release cycle?
Wont help in this case. The old API was really botched.
So, what do we do?
Stefano.
!)
Now, in the spirit of stop building on sand, I wanted to propose to ship
the lastest ant release.
Is anybody against that?
Stefano.
Diana Shannon wrote:
On Saturday, March 22, 2003, at 04:53 AM, Stefano Mazzocchi wrote:
Inside, we are all equal so once you get it can either be a democracy
(ask first, wait for momentum to build, potentially forever) or a
do-ocracy (do first, rollback if they jump on you or keep going
is taking care of slide?
i can reproduce #1 on jsp, I'll investigate right after this.
hopefully found a way to fix #3.
Ah, Sam, Steven, how do I access that cocoon-special gump stuff on
cocoondev.org? that would likely reduce the try/fail cycle of 24 hours
that is driving me nuts!
Stefano.
Diana Shannon wrote:
On Saturday, March 22, 2003, at 11:13 AM, Stefano Mazzocchi wrote:
Perhaps it's just the nature of open source software, that a
tremendous amount of energy is unleashed right before a release date.
Perhaps there's no other way. Still, it feels, to be honest, like
poor
in and thereby far away from
being relased. IIRC we wanted to go with release versions only - right?
A very big temptation though :-/
If Avalon is not confident enough to release it, why should we?
Stefano.
is not confident enough to release it, why should we?
Didn't want to imply we should - just that it would be awesome if
Avalon would release it soon :)
I agree. So let's nag them :)
Stefano.
Geoff Howard wrote:
By the way, I think there are bigger security problems in cocoon...
Like what? (not being arrogant or defensive, just curious... damn email
communication sometimes coveys the wrong tone)
Stefano.
this (and Nicola's suggestion) I think it's a nice and sane
plan of action.
Stefano.
fixed it.
Sam, Nicola, any suggestion?
Stefano.
.
the really broken ones are:
- fop
- slide
where we depend on classes now missing.
Does anybody know what's wrong with these packages and how hard it would
be to solve the issues?
TIA
Stefano.
checking)
Stefano.
so, probably all of you wouldn't be here by now :)
Food for thought.
Stefano.
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
Why can't se simply postpone module-creation this after 2.1? I don't
think it's worth delaying further for a simple 50kb less of cocoon.jar
I agreed that we move this issue into 2.2 or whatever and that this
should not delay 2.1 - so for me
, brother, Amen :)
Stefano.
wrong, I love to be criticized, I love to be talked
directly, even when it hurts. I love to crush my own ego and see what
remains. I love to learn and earn respect by learning and teaching and
doing stuff.
But I expect others to do the same and this is my big mistake.
Stefano.
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 20/03/2003 12.23:
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
Why can't se simply postpone module-creation this after 2.1? I don't
think it's worth delaying further for a simple 50kb less of cocoon.jar
I agreed that we move this issue
from the cocoon CLI!
2) write a pretty detailed comment in the default sitemap telling what
views are, how they work briefly and what potential security issues do
they make.
3) keep the view parameter name hardcoded as it is.
Thoughts? anybody against this?
Stefano.
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 18/03/2003 13.05:
Nicola Ken Barozzi wrote:
...
So, how would you tackle the above real-world problem?
I would not write a transformer but a serializer. In fact, a chart
package image rendere *is* a serializer, since the output
Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Christopher Oliver wrote:
http://cvs.apache.org/viewcvs.cgi/*checkout*/cocoon-2.1/src/java/org/apache/cocoon/components/flow/javascript/xmlForm.js?rev=1.3content-type=text/plain
In order to communicate with XMLFormTransformer and to handle
.
Now, if my sitemap doesn't use *any* flow elements, would the jar need
to be in the classloader?
Stefano.
Memory leak in use of StringBuffer.toString()
Holy shit! This is a *HUGE* bug. We (and Xerces) use StringBuffers all
over the place!!! In fact, it seems that StringBuffer.toString() is our
hotspot.
I'll come up with more profile information soon.
Stefano.
.
Stefano.
Sylvain Wallez wrote:
Now, if my sitemap doesn't use *any* flow elements, would the jar need
to be in the classloader?
Nope, since the flow-related treeprocessor classes deal with flow
interfaces rather than with the JS implementation. So we need the
flow-related interfaces (only
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to
the environment (Request / Response). This means that it is very hard
to write sophisticated Serializers.
For example? (I think FOP and batik are both
Jeff Turner wrote:
Hi,
Generator, Reader and Transformer all inherit from
SitemapModelComponent, which declares the setup() method:
public interface SitemapModelComponent extends Component {
/**
* Set the codeSourceResolver/code, objectModel
* codeMap/code, the source and sitemap
Jakob Praher wrote:
Index: blocks-build.xsl
===
RCS file: /home/cvspublic/xml-cocoon2/tools/src/blocks-build.xsl,v
retrieving revision 1.26
diff -u -r1.26 blocks-build.xsl
--- blocks-build.xsl 3 Mar 2003 14:03:34 - 1.26
+++
class in the rt.jar file with the 1.4.0
counterpart... scary :-)).
I thought about doing it. I admit :)
Yet it would be *much* better have a 1.4.1.x
out RSN to fix this important issue.
Hopefully.
Stefano.
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
One word: CacheableProcessingComponent. IIRC, cache was aware of
cacheable serializers some time ago. The only missing piece is to add
SitemapModelComponent support for Serializers.
Yes, the caching algorithm queries serializers if they support
. There is a CVS for that.
Stefano.
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
I personally don't like it. Adding fake facades for just one thing
doesn't sound right at all.
I think that Carsten's problem is to have an external dependency on the
rhino jar. Please, Carsten, correct me if I'm wrong.
Not exactly. Yes, I
HPjmeter (nothing related to our good old Apache JMeter)
4) run it
5) load the java.hprof.txt in that
6) enjoy.
Stefano.
David Crossley wrote:
Stefano Mazzocchi wrote:
David Crossley wrote:
snip/
Found it - there is extra whitespace at the end of these
three lines in block.properties, i.e. after the =true
Thank the lord, i am not going mad. Sounds like we
need normalize-space() whenever properties are read.
Call
Vadim Gritsenko wrote:
Pier Fumagalli wrote:
On 17/3/03 20:15, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
snip/
What about adding a 'content encoding' attribute to the 'pipeline'
instead?
'transfer encoding' attribute would make sense, but content encoding...
wait wait wait
I'm using
might facilitate migration from one approach to another, also
will allow integration between different parts.
This is a good point.
What do others think?
Stefano.
to lucene/webapp then forgot to commit and got lot
when I switched my laptop.
But I'm sure somebody has a backup copy of those floating around. Anybody?
Stefano.
Nicola Ken Barozzi wrote:
David Crossley wrote, On 18/03/2003 3.37:
Stefano Mazzocchi wrote:
David Crossley wrote:
snip/
Found it - there is extra whitespace at the end of these
three lines in block.properties, i.e. after the =true
Thank the lord, i am not going mad. Sounds like we
need
.
Stefano.
Ugo Cei wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
1) do we really need the session object? the flow is in fact
deprecating the use of sessions for storing stateful data. I would
love to *force* people to think into this way by not making the
session available to them. We can
with this?
Stefano.
memory.
I'm currently experimenting with other profilers so expect more data soon.
Stefano.
Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Great, integration between different not-all-flowable parts is a
*real* need for sessions in the FOM.
So +1 to add it.
Anybody against it?
Stefano.
-1 for this reason. As mentioned in other mails, direct access to the
session isn't needed
Christopher Oliver wrote:
Pier Fumagalli wrote:
On 17/3/03 20:02, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, I would go for
global - contains global log methods, no properties
global doesn't have a meaning in IDL, therefore I created the Script
object, which will contain also
Sylvain Wallez wrote:
Pier Fumagalli wrote:
On 18/3/03 21:29, Christopher Oliver [EMAIL PROTECTED] wrote:
Stefano Mazzocchi wrote:
Another possibility is to only expose the session at the Java level
(not JavaScript) forcing new JavaScript objects that need access to it
to be written
Pier Fumagalli wrote:
On 18/3/03 21:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
I assume, but I'm not sure, that [xx are native internal objects, so
there is not much we can do about those. Still, I would like to know
what is that [10 object that accounts for so much memory.
They should
Pier Fumagalli wrote:
On 18/3/03 23:00, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
But I have the impression i didn't understand what Pier was implying
because I'm sure he would not propose to force people to write that much
java gluecode just for everyday FOM usage.
Pier, can you elaborate more
cocoon.environment.objectModel
cocoon.forwardTo()
Why do you need direct access to the objectModel?
My 'script kid' alarm is ringing.
Stefano.
classconstants/
/filterchain
/loadproperties
Uh, cool, but that class would need to be compiled first, then imported
and so on. I think it's better to keep it the way it is now.
Stefano.
Christopher Oliver wrote:
Found it:
http://bugs.eclipse.org/bugs/show_bug.cgi?id=34658#c28
ah, that also explains some random problems I'm experiencing with
Eclipse... it appears to be a problem with the JDK 1.4.1 macosx
implementation of InputStream.available() which is a native function.
Wow,
David Crossley wrote:
David Crossley wrote:
David Crossley wrote:
Stefano Mazzocchi wrote:
snip/
try to do a clean checkout, maybe there is something wrong in
your local CVS metadata.
ah, no, wait, what settings are you using for cvs update?
cvs -q -z3 update -d -P cocoon-2.1
Okay, i will try
separate I'm all for it, but elegant integration is, IMO, more important
than potential separation.
Stefano.
number
reporting on exceptions
On top of my head: is it fair to call this 'rhino' anymore?
I'm not suggesting to fork, but I'm wondering what others think about this.
Stefano.
Sylvain Wallez wrote:
What I suggested in the mail linked above is to use the object model,
already used as a communication means between the environment and other
components to communicate flow results. This suggestion comes both from
the fact that the object model is the natural way for the
Pier Fumagalli wrote:
On 16/3/03 20:04, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
So, if you to put encoding into sitemap... You will have to disable
serializer configuration and request configuration and force sitemap
encoding onto request / response. Is this what you are proposing
, as those might change for the same request URL depending on the
different headers in the request...
Uh, another good point.
Stefano.
Pier Fumagalli wrote:
On 15/3/03 21:54, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
- flow
- provide a block-like method for extension of the object model
What about something similar to Mozilla's XPConnect?
http://www.mozilla.org/scriptable/
No, I don't think this is what we need. XPConnect
is
a prerequisite to a 2.1 beta or even final.
I agree.
Oh, that's no problem for me.
Carsten, you propsed the move: what's your feeling about this?
Stefano.
in local.block.properties all
entries from
#exclude.block.XXX=true to
exclude.block.XXX=true
and no block compilation was performed.
which block is broken?
Thanks to Bernhard and Stefano for following up.
However, i still get the same problem with today's CVS.
The Lucene block is broken and i cannot get
Cocoon is heavily internationalized but we fail to do one thing: signal
the proper encoding to the user-agent thru HTTP headers, which is the
most reliable way of doing it.
the current *hack* is to use meta tags in the HTML stream, these are
interpreted by the HTTP server stack and transfered
to simplify them
by a great deal and I would like you to be involved because you know all
the pieces of the puzzle.
This is not so critical so can be postponed at post-2.1 release, but
this will have to be done and I would like to know your comments about this.
Stefano.
J2EE and
.NET in a short while.
We must be prepared for the flood of people that will *wow* over this
and flood our mail lists.
This is why i want to solidify the flow contracts.
Postponing this after 2.1 is, IMHO, a potential community suicide.
Stefano.
201 - 300 of 1807 matches
Mail list logo
