[Fwd: Maven 1.0-RC1 released]

[Stephen McConnell]

Just for reference.
http://maven.apache.org/builds/release/1.0-rc1/
Steve.
 Original Message 
Subject:Maven 1.0-RC1 released
Date:   Mon, 29 Sep 2003 16:43:39 +1000
From:   [EMAIL PROTECTED]
Reply-To:   Maven Developers List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


The Maven team is pleased to announce Release Candidate 1!

http://maven.apache.org/

Maven is a Java project management and project comprehension tool. Maven
is based on the concept of a project object model (POM) in that all the
artifacts produced by Maven are a result of consulting a well defined
model for your project. Builds, documentation, source metrics, and
source cross-references are all controlled by your POM.
Maven has many goals, but in a nutshell Maven aims to make the
developer's life easier by providing a well defined project structure,
well defined development processes to follow, and a coherent body of
documentation that keeps your developers and clients apprised of what's
happening with your project. Maven alleviates a lot of what most
developers consider drudgery and lets them get on with the task at hand.
This is essential in OSS projects where there aren't many people
dedicated to the task of documenting and propagating the critical
information about your project which is necessary in order to attract
potential new developers and clients.
This version is primarily a bugfix release.

Bugs fixed
--
see 
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10030&fixfor=10181

Bugs to be fixed for 1.0

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10030&fixfor=10149
You can find the Maven distributions here:
http://maven.apache.org/builds/release/1.0-rc1/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]

RE: Castor support in Cocoon (was: Building cocoon: where are block descriptions?)

[Carsten Ziegeler]

Reinhard Poetz wrote:
> 
> > From: Carsten Ziegeler
> > 
> > Reinhard Poetz wrote:
> > > 
> > > > PS Speaking of which, can somebody enlighten me as to why the
> > > > CastorTransformer still is part of the scratchpad 
> > > > block. And what would it take to move it to its separate block ?
> > > 
> > > I remember we already discussed this before 2.1 was released and we 
> > > said that we didn't want a block so short before the release.
> > > 
> > > Secondly, the new portal stuff uses Castor too and the two 
> > approaches 
> > > should be unified. Carsten, do you have any suggestions (I think it 
> > > was you who suggested this).
> > > 
> > Hmm, I'm not sure if I suggested this...weak memory.
> > But the portal uses a persistence component (persistent the 
> > portal profile in an xml doc and vice versa) and this 
> > component uses Castor. This is a general component which 
> > perhaps could be used from the 
> > transformer?
> 
> Yep, I think this is what you've proposed.
> 
> So we can put the complete castor stuff into a new 'castor' block,
> containing the transformer and the "persistence component" and maybe a
> generator. The new portal block will then depend on this castor block.
> Is this okay for you?
> 
Yes.

Carsten

Re: [OT] I am back...

[Sylvain Wallez]

Torsten Curdt wrote:

Dear community, friends and folks,

somehow I feel I should explain why I almost disappeared from this 
list and became more a lurker than an active member of this community. 
I know I don't have to ...but I feel better doing so.

Finally it's official - some of you might know it already: I am no 
longer at dff internet & medien. Within the last months finishing the 
last projects and leaving dff took most of my time and energy. So 
Instead of only being able to paticipate half-heartedly I decided to 
better keep my mouth shut.

Anyway... I'm back :) ...looking forward on lot's of RT, discussions, 
the upcoming challenges and especially meeting you guys at the 
GetTogether again! 


Welcome back, Torsten!

Thanks to orixo for organizing the GetTogether. Thanks to you guys for 
being the community that I am glad to be a part of. 


Thanks for the plug : for those want to come but aren't yet registred, 
hurry up and go at http://www.orixo.com/events/gt2003/ !!

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: The granularity of continuations

[Sylvain Wallez]

Christopher Oliver wrote:

Ok, ok. I've checked in an implemention of arguments.continuation into 
the Rhino cvs on cocoondev.org.  Please test it and let me know if 
it's ok.  If so, someone can go ahead and update the cocoon cvs.


Chris, I don't know what's your state of mind about this (we already had 
communication problems in the past), but I'd like to make it clear that 
I don't want to impose anything. I simply had problems understanding the 
real behaviour of continuations, and this "new Continuation()" was part 
of these problems. I would have been happier with some agreement from 
you, rather than a simple "ok, ok" that makes me think you were bored by 
my remarks.

I also would like some feedback from other non-Schemers around there to 
know their feelings about this. Or am I the only one that digged so deep 
in the flowscript internals ?

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

RE: Castor support in Cocoon (was: Building cocoon: where are block descriptions?)

[Reinhard Poetz]

> From: Carsten Ziegeler
> 
> Reinhard Poetz wrote:
> > 
> > > PS Speaking of which, can somebody enlighten me as to why the
> > > CastorTransformer still is part of the scratchpad 
> > > block. And what would it take to move it to its separate block ?
> > 
> > I remember we already discussed this before 2.1 was released and we 
> > said that we didn't want a block so short before the release.
> > 
> > Secondly, the new portal stuff uses Castor too and the two 
> approaches 
> > should be unified. Carsten, do you have any suggestions (I think it 
> > was you who suggested this).
> > 
> Hmm, I'm not sure if I suggested this...weak memory.
> But the portal uses a persistence component (persistent the 
> portal profile in an xml doc and vice versa) and this 
> component uses Castor. This is a general component which 
> perhaps could be used from the 
> transformer?

Yep, I think this is what you've proposed.

So we can put the complete castor stuff into a new 'castor' block,
containing the transformer and the "persistence component" and maybe a
generator. The new portal block will then depend on this castor block.
Is this okay for you?

Reinhard

RE: [Portal] how to load a coplet before an other ?

[Carsten Ziegeler]

Olivier Billard wrote:
> 
> Are they some samples dealing with events, or a way to find some doc ?
> 
Sorry, not that I'm aware of...

Carsten

RE: Castor support in Cocoon (was: Building cocoon: where are block descriptions?)

[Carsten Ziegeler]

Reinhard Poetz wrote:
> 
> > PS Speaking of which, can somebody enlighten me as to why the 
> > CastorTransformer still is part of the scratchpad 
> > block. And what would it take to move it to its separate block ?
> 
> I remember we already discussed this before 2.1 was released and we said
> that we didn't want a block so short before the release. 
> 
> Secondly, the new portal stuff uses Castor too and the two approaches
> should be unified. 
> Carsten, do you have any suggestions (I think it was you who suggested
> this).
> 
Hmm, I'm not sure if I suggested this...weak memory.
But the portal uses a persistence component (persistent the portal
profile in an xml doc and vice versa) and this component uses Castor.
This is a general component which perhaps could be used from the 
transformer?

Carsten

Re: Unit testing pipelines?

[Upayavira]

Steve K wrote:

Hello everyone --

I am currently building a Cocoon application and so far I've extended 
the ExcaliburTestCase class to write my JUnit tests for the components 
I'm creating.  However, I'm now at the point where I am starting to 
write pipelines that generate XML based on the database manipulations 
the previously mentioned components perform, and it appears that there 
is no easy way to test these.  For example, my ideal test code might 
look like:

myCustomComponent.doSomething();
Document actualXml = cocoon.process("/path/to/my/pipeline");
Diff diff = new Diff(actualXml, expectedXml);
assertTrue("pipeline test", diff.identical());
I suppose I could use something like HTTPUnit here, and set up a test 
script to start cocoon, request the uri and parse the result into 
XML...  but that seems a little messier than it should be.

I've looked at the CocoonBean stuff, and while it is close, it seems 
geared toward publishing pages rather than embedding cocoon and 
directly calling pipelines.

Does this sound like a good idea, or is everyone just using HTTPUnit 
for this level of testing?  Might it be possible to modify CocoonBean 
to allow direct access to the result of calling a pipeline?  Does 
anyone think unit testing pipelines this way is actually valuable?
Steve,

The bean is intended to be a programmatic interface to Cocoon, not just 
for publishing. There is a method (I'm not sure how well it works 
though, but I can check), to write the contents of a pipeline to an 
output stream, which is closer to what you are talking about.

You could do what you're talking about by implementing a 
UnitTestingPipeline, to replace the default CachingProcessingPipeline.

So what you'd do is, in the Bean, pass in a set of 'expected' XMLs'. for 
each stage of the pipeline. The Bean puts these details into the 
environment, available for the pipeline. When generating a page, the 
UnitTestingPipeline, as well as passing the content of the stage on to 
the next stage, takes a copy and compares it to the relevant 'expected 
XML' for that stage. If you look at AbstractCachingPointPipeline, I 
think you'll see a pipeline that more or less does this, in order to 
cache the content. You could replace that with code to test the XML.

So, a UnitTestingPipeline in combination with extensions to the CLI/Bean 
to be able to configure this pipeline, wouldn't be too hard to 
implement. Are you interested?

Regards, Upayavira

Re: [RT] Performance Block

[Bertrand Delacretaz]

Le Dimanche, 28 sep 2003, à 16:28 Europe/Zurich, Reinhard Poetz a écrit 
:
...Following all those considerations I want to propose the creation 
of a
new "performance" block that is ready to use for load tests - it should
contain:

 - one or more sample applications following Cocoon design patterns
 - performance optimized Cocoon configuration
 - JMeter integration
 - new Ant build target that creates all necessary things
   to run a test within the user's environment:
   * container (Jetty)
   * application
   * JMeter including the test script
Wouldn't it be possible to include JMeter scripts in each block where 
one wants to test performance?

Then, the performance block could find out which blocks are ready for 
performance testing and allow any of them to be tested.

Would be more useful than "just" testing one or two sample apps IMHO.

 ... and the user can enter
 - how much memory he wants to provide for the test
 - the number of concurrent users
 - the duration
 and the cocoon.xconf, the various pool sizes and the settings
 for the JVM are set accordingly...
Sounds good but the tester should also be warned that there is more to 
Cocoon tuning than just setting available memory.

-Bertrand

Re: Event handling in Woody

[Andreas Hochsteger]

Sylvain Wallez wrote:
Andreas Hochsteger wrote:

Sylvain Wallez wrote:




Now handlers involving widgets only (and not app-data) may be sent to 
the client, but this would require to reconsitute an equivalent of 
the form model on the client. Not easy, but I'm not a client-side JS 
expert... Want to give it a try ?


I'm not either ... :-(

One more question comes to my mind:
How hard would it be to support XUL applications with Woody?


Look at woody-field-styling.xsl and woody-page-styling.xsl and write 
their XUL version ! Want to give it a try, this time ? ;-)
Perhaps ;-)

Sylvain

Andreas

Re: The granularity of continuations

[Christopher Oliver]

Ok, ok. I've checked in an implemention of arguments.continuation into 
the Rhino cvs on cocoondev.org.  Please test it and let me know if it's 
ok.  If so, someone can go ahead and update the cocoon cvs.

Regards,

Chris

Sylvain Wallez wrote:

Sylvain Wallez wrote:



Now back to the syntactic problem. I digged a bit and found the 
definition of the Scheme continuation at [1]. And although Rhino's 
continuations may follow that of Scheme, I see no real possible 
comparison between the respective syntaxes :
- Scheme's "call/cc" passes the continuation to its single parameter 
which is a procedure and executes this procedure. And the 
continuation (AFAIU) captures the state at its invocation point and 
not the state of the enclosing function.
- Rhino's "new Continuation()" captures the continuation of the 
enclosing function call and returns it, without further processing. 


Update: after thinking further, I understand how Rhino and Scheme 
syntaxes relate. Rhino's function in which "new Continuation()" is 
called is actually the equivalent to the argument of call/cc.

But IMO this only enforces the fact that we don't *create* a 
continuation, but just *get* that of the enclosing function.

Sylvain

Re: [Vote] Build infrastructure

[Stephen McConnell]

Having been though the process of setting up Maven for several projects 
- and during the process experienced the evolution form Maven 0.7 to the 
current 0.10, I can confirm that Maven in its current form is usable and 
functional.

There are bugs in the Maven 10 release, many of which have been resolved 
under the imminent beta 11/RC1.  There are also a number of defensive 
practices that can be employed to minimise problems.  There are several 
examples of maven based builds in Avalon - the Framework 4.1.5 release, 
the recently released Avalon Meta 1.1 package, a number of recently 
converted Excalibur packages (i18n 1.1 and configuration and 1.1), and 
the new Merlin 3.0 container release.  These collectively represent a 
total of more than 40 maven subprojects consolidated under 5 parent 
project.

Stephen.

Joerg Heinicke wrote:

Giacomo Pati wrote:


3) Maven
ATM this is my preferred build infrastructure and I could help
building the 2.2 repo based on it


Heard interesting things it (besides the opinion that there is 
nearly no

  ^^^^

documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
necessary flexibility into Ant.


What do you mean with 'there is nearly no documentation'? About Maven
itself? I've found the web site and other resources quite enough to
start using it for sever projects now. What do you miss?


See above. I didn't have a look on it myself. It was about Maven and 
especially Jelly. And as far Maven uses Jelly ...

Joerg


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]

[OT] I am back...

[Torsten Curdt]

Dear community, friends and folks,

somehow I feel I should explain why I almost disappeared from
this list and became more a lurker than an active member of this
community. I know I don't have to ...but I feel better doing so.
Finally it's official - some of you might know it already:
I am no longer at dff internet & medien. Within the last months
finishing the last projects and leaving dff took most of my
time and energy. So Instead of only being able to paticipate
half-heartedly I decided to better keep my mouth shut.
Anyway... I'm back :) ...looking forward on lot's of RT, discussions,
the upcoming challenges and especially meeting you guys at the
GetTogether again!
Thanks to orixo for organizing the GetTogether. Thanks to you guys
for being the community that I am glad to be a part of.
cheers
--
Torsten
PS: I might wanna do some traveling first but job offers are
still welcome ;)

Unit testing pipelines?

[Steve K]

Hello everyone --

I am currently building a Cocoon application and so far I've extended 
the ExcaliburTestCase class to write my JUnit tests for the components 
I'm creating.  However, I'm now at the point where I am starting to 
write pipelines that generate XML based on the database manipulations 
the previously mentioned components perform, and it appears that there 
is no easy way to test these.  For example, my ideal test code might 
look like:

myCustomComponent.doSomething();
Document actualXml = cocoon.process("/path/to/my/pipeline");
Diff diff = new Diff(actualXml, expectedXml);
assertTrue("pipeline test", diff.identical());
I suppose I could use something like HTTPUnit here, and set up a test 
script to start cocoon, request the uri and parse the result into XML... 
 but that seems a little messier than it should be.

I've looked at the CocoonBean stuff, and while it is close, it seems 
geared toward publishing pages rather than embedding cocoon and directly 
calling pipelines.

Does this sound like a good idea, or is everyone just using HTTPUnit for 
this level of testing?  Might it be possible to modify CocoonBean to 
allow direct access to the result of calling a pipeline?  Does anyone 
think unit testing pipelines this way is actually valuable?

thanks for any advice,
-steve

Re: [Vote] Build infrastructure

[Joerg Heinicke]

Giacomo Pati wrote:

3) Maven
ATM this is my preferred build infrastructure and I could help
building the 2.2 repo based on it
Heard interesting things it (besides the opinion that there is nearly no
  ^^^^

documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
necessary flexibility into Ant.


What do you mean with 'there is nearly no documentation'? About Maven
itself? I've found the web site and other resources quite enough to
start using it for sever projects now. What do you miss?
See above. I didn't have a look on it myself. It was about Maven and 
especially Jelly. And as far Maven uses Jelly ...

Joerg

Re: The granularity of continuations

[Sylvain Wallez]

Sylvain Wallez wrote:



Now back to the syntactic problem. I digged a bit and found the 
definition of the Scheme continuation at [1]. And although Rhino's 
continuations may follow that of Scheme, I see no real possible 
comparison between the respective syntaxes :
- Scheme's "call/cc" passes the continuation to its single parameter 
which is a procedure and executes this procedure. And the continuation 
(AFAIU) captures the state at its invocation point and not the state 
of the enclosing function.
- Rhino's "new Continuation()" captures the continuation of the 
enclosing function call and returns it, without further processing. 


Update: after thinking further, I understand how Rhino and Scheme 
syntaxes relate. Rhino's function in which "new Continuation()" is 
called is actually the equivalent to the argument of call/cc.

But IMO this only enforces the fact that we don't *create* a 
continuation, but just *get* that of the enclosing function.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: The granularity of continuations

[Sylvain Wallez]

Christopher Oliver wrote:

The code

   new Continuation()

returns an object representing the continuation of the current 
function invocation. I don't see why that is confusing (if you 
understand the concept of continuations in the first place). The 
created object is itself a function. When you invoke it it causes that 
function invocation to return with the value you pass as an argument. 
This is the same behavior as in Scheme. I personally don't see a 
problem here...


First, thanks for confirming my understanding. Now there are several 
interesting points in what you say. Warning, we enter a highly 
subjective discussion.

You point out precisely the problem, but don't see its importance as you 
enclose it with parenthesis : "if you understand the concept of 
continuations in the first place". This is the key, as *most people 
using Cocoon have never heard of Scheme nor of continuations*.

This means that most people (including myself, even if I did a 
reasonable amount of Lisp 15 years ago) have hard times understanding 
the details of exactly how continuations behave and what gets captured. 
Sure, sendPageAndWait() provides a simple wrapper to use continuations 
without knowing, but going further or even understanding that handling 
of the back button depends on how variable declarations are intermingled 
with continuations require a more precise understanding of what happens 
under the hood. And having a syntax that encourages misunderstanding is 
not good in this regard.

Now back to the syntactic problem. I digged a bit and found the 
definition of the Scheme continuation at [1]. And although Rhino's 
continuations may follow that of Scheme, I see no real possible 
comparison between the respective syntaxes :
- Scheme's "call/cc" passes the continuation to its single parameter 
which is a procedure and executes this procedure. And the continuation 
(AFAIU) captures the state at its invocation point and not the state of 
the enclosing function.
- Rhino's "new Continuation()" captures the continuation of the 
enclosing function call and returns it, without further processing.

I have no problem with the fact that Rhino's approach doesn't have a 
function as argument, and that it captures the enclosing function, but 
I'm concerned by the mismatch caused by the fact that the implied 
meaning of the continuation creation statement is so much decorrelated 
from the function itself.

Consider the following :
 function someFunction() {
 var k1 = new Continuation();
 var k2;
 // nested control structure
 for (var i = 0; i < 1; i++) {
 k2 = new Continuation();
 }
 print("k1 == k2 is " + k1 == k2);
 return k1; // or k2...
 }
The result is "k1 == k2 is false", which seems good considering the code 
from the procedural point of view, but *k1 and k2 are totally 
equivalent*. Calling one or the other will lead to exactly the same 
result. Isn't this confusing ? At least it confused me, and I guess many 
others will be confused also.

That's what I'm proposing a different notation that unambiguously 
relates the continuation with the function. And the 
"arguments.continuation" notation seems good to me as "arguments" 
relates to the current function call (just as "argument.callee" returns 
the function itself).

Yeah, that's nitpicking, but I consider this important as continuations 
are incredibly powerful, but not that easy to understand. This has 
already been shown by numerous posts. And a clear syntax is IMO key to 
its wide adoption.

Sylvain

[1] http://www.scheme.com/tspl2d/control.html#g1965

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: [Vote] Build infrastructure

[Giacomo Pati]

On Sun, 28 Sep 2003, Joerg Heinicke wrote:

> Giacomo Pati wrote:
>
> > Well, as my time permits it and Berin could give a hand as well, why
> > not.
> >
> > But first we need to come to a consensus about which build
> > infrastructure we would support to use:
> >
> > 1) Ant
> >  in this case we can use the current build system and tune it to the
> >  needs we have for the 2.2 and maybe add some ruper task to get rid
> >  of jars in our repository (suggested by Nicola Ken IIRC) and some
> >  more for modularisation ease
>
> IMO Ant is inflexible in general and adding flexibility (e.g. by using
> parameterized antcall) slows down the build process.
>
> > 2) Centipede
> >  in this case I could not volunteer as I'm out of Centipede since
> >  their move from Cents to Antlibs (we still have some customer
> >  project using a Cents based version of it but they will never move
> >  to Antlibs)
>
> Can not evaluate it.
>
> > 3) Maven
> >  ATM this is my preferred build infrastructure and I could help
> >  building the 2.2 repo based on it
>
> Heard interesting things it (besides the opinion that there is nearly no
> documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the
> necessary flexibility into Ant.

What do you mean with 'there is nearly no documentation'? About Maven
itself? I've found the web site and other resources quite enough to
start using it for sever projects now. What do you miss?

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: [Vote] Build infrastructure (was: on better release and version management)

[Antonio Gallardo]

Giacomo Pati dijo:
> On Sun, 28 Sep 2003, Antonio Gallardo wrote:
>> Then Ant can be present in the 3 options presented. I share with you
>> the need to move to a better project management. In that case I think
>> the question is related to Centiped vs. Maven.
>
> Well, all three infrastructure mentioned above are Ant, Ant based or use
> Ant. I mentiond 1) because Stefano argumented that the build
> infratruction at present is good enough in his eyes.

Hmm. On one side it is true. Since Ant is doing his job right now, we does
not need more probes of the current build system. It is good, because it
is working.

On the other way, I think our job (as Cocoon developers) is to enhance and
mantain the Cocoon project, we dont need to create a build system or a
project management tool. For these taks there are Maven or Centipede
project. I though the guys behind both projects really likes they do and
know what they are doing. We can benefits from this. Note, we are not
building or trying to build an Ant-like tool. The Ant guys do this work.

I think it is better to save our efforts by using any of the projects
related to this tasks. The idea, is to have a better project management
with less effort than we currently have with Ant. Is that right?

Note: I am not a Maven nor Centipede guru. But the promise behind any of
both projects is good.

Best Regards,

Antonio Gallardo.

Re: Event handling in Woody

[Sylvain Wallez]

Andreas Hochsteger wrote:

Sylvain Wallez wrote:


Now handlers involving widgets only (and not app-data) may be sent to 
the client, but this would require to reconsitute an equivalent of 
the form model on the client. Not easy, but I'm not a client-side JS 
expert... Want to give it a try ?


I'm not either ... :-(

One more question comes to my mind:
How hard would it be to support XUL applications with Woody?


Look at woody-field-styling.xsl and woody-page-styling.xsl and write 
their XUL version ! Want to give it a try, this time ? ;-)

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: [Vote] Build infrastructure (was: on better release and version management)

[Giacomo Pati]

On Sun, 28 Sep 2003, Antonio Gallardo wrote:

> Giacomo Pati dijo:
> > But first we need to come to a consensus about which build
> > infrastructure we would support to use:
> >
> > 1) Ant
> >  in this case we can use the current build system and tune it to the
> > needs we have for the 2.2 and maybe add some ruper task to get rid
> > of jars in our repository (suggested by Nicola Ken IIRC) and some
> > more for modularisation ease
> >
> > 2) Centipede
> >  in this case I could not volunteer as I'm out of Centipede since
> > their move from Cents to Antlibs (we still have some customer
> > project using a Cents based version of it but they will never move
> > to Antlibs)
> >
> > 3) Maven
> >  ATM this is my preferred build infrastructure and I could help
> > building the 2.2 repo based on it
>
> Hi:
>
> I think this Ant vs. (Centipede or Maven) is a not fair comparation. Check
> this: http://www-106.ibm.com/developerworks/java/library/j-maven/
>
> From the above document:
> 
> A Maven goal can contain any valid Ant task in its definition, which will
> help you quickly learn Maven and protect your Ant investments.
> 
>
> Then Ant can be present in the 3 options presented. I share with you the
> need to move to a better project management. In that case I think the
> question is related to Centiped vs. Maven.

Well, all three infrastructure mentioned above are Ant, Ant based or use
Ant. I mentiond 1) because Stefano argumented that the build
infratruction at present is good enough in his eyes.

> With this options presented, my vote is:
>
> Maven +1
>
> Best Regards,
>
> Antonio Gallardo.
>
>
>

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: [Vote] Build infrastructure

[Joerg Heinicke]

Giacomo Pati wrote:

Well, as my time permits it and Berin could give a hand as well, why
not.
But first we need to come to a consensus about which build
infrastructure we would support to use:
1) Ant
 in this case we can use the current build system and tune it to the
 needs we have for the 2.2 and maybe add some ruper task to get rid
 of jars in our repository (suggested by Nicola Ken IIRC) and some
 more for modularisation ease
IMO Ant is inflexible in general and adding flexibility (e.g. by using 
parameterized antcall) slows down the build process.

2) Centipede
 in this case I could not volunteer as I'm out of Centipede since
 their move from Cents to Antlibs (we still have some customer
 project using a Cents based version of it but they will never move
 to Antlibs)
Can not evaluate it.

3) Maven
 ATM this is my preferred build infrastructure and I could help
 building the 2.2 repo based on it
Heard interesting things it (besides the opinion that there is nearly no 
documentation ;-) ), so +1 from here too. Jelly/Maven seem to bring the 
necessary flexibility into Ant.

Joerg

Re: Event handling in Woody

[Andreas Hochsteger]

Sylvain Wallez wrote:

Andreas Hochsteger wrote:

Hi Sylvain!

Sylvain Wallez wrote:



I solved points 3&4 as follows :
-  are considered as "intra-form" actions : they never 
validate and always redisplay the form
-  (new widget that extends action) are considered as 
"form-exit" actions. They have an additional "validate" attribute 
that define if form validation should occur (true by default). For 
example, this allows a "cancel" button to be written as 


Would it be possible (perhaps in the future) to handle those 
intra-form actions completely on the client (eg. via JavaScript)?
Imagine using some DHTML to add or delete rows...

Not that I'd need it right now, but I'm just curious, if you thought 
about something like that.


Yes, I thought about that, and I even wrote some add/remove stuff for 
XMLForm before switching to Woody. But this can be very tricky to do as 
it highly depends on how the form widgets map to HTML code.
>
And since this mapping is defined by the form template, you can't rely 
on the fact that a repeater is laid out in a particular way. This could 
be done, however, if the layout of a repeater was templated using a new 
instance-only widget like the wi:group defined in "woody-page-styling.xsl".

Now the repeaters are only a small part of event-handling, as actions 
can be used to do many other things such as getting the (parsed and 
validated) value of other fields, accessing application data, etc. This 
server-side event handling allow to simply define complex form 
interactions at the cost of a roundtrip to the server. I'm currenlty 
investingating in moving form styling on XSL-enabled clients (Mozilla 
and IE6) which would speed up this rountripping.

Now handlers involving widgets only (and not app-data) may be sent to 
the client, but this would require to reconsitute an equivalent of the 
form model on the client. Not easy, but I'm not a client-side JS 
expert... Want to give it a try ?
I'm not either ... :-(

One more question comes to my mind:
How hard would it be to support XUL applications with Woody?
Sylvain

Andreas

Re: [Vote] Build infrastructure (was: on better release and version management)

[Antonio Gallardo]

Giacomo Pati dijo:
> But first we need to come to a consensus about which build
> infrastructure we would support to use:
>
> 1) Ant
>  in this case we can use the current build system and tune it to the
> needs we have for the 2.2 and maybe add some ruper task to get rid
> of jars in our repository (suggested by Nicola Ken IIRC) and some
> more for modularisation ease
>
> 2) Centipede
>  in this case I could not volunteer as I'm out of Centipede since
> their move from Cents to Antlibs (we still have some customer
> project using a Cents based version of it but they will never move
> to Antlibs)
>
> 3) Maven
>  ATM this is my preferred build infrastructure and I could help
> building the 2.2 repo based on it

Hi:

I think this Ant vs. (Centipede or Maven) is a not fair comparation. Check
this: http://www-106.ibm.com/developerworks/java/library/j-maven/

>From the above document:

A Maven goal can contain any valid Ant task in its definition, which will
help you quickly learn Maven and protect your Ant investments.


Then Ant can be present in the 3 options presented. I share with you the
need to move to a better project management. In that case I think the
question is related to Centiped vs. Maven.

With this options presented, my vote is:

Maven +1

Best Regards,

Antonio Gallardo.

Re: The granularity of continuations

[Christopher Oliver]

The code

   new Continuation()

returns an object representing the continuation of the current function 
invocation. I don't see why that is confusing (if you understand the 
concept of continuations in the first place). The created object is 
itself a function. When you invoke it it causes that function invocation 
to return with the value you pass as an argument. This is the same 
behavior as in Scheme. I personally don't see a problem here...

My $0.02,

Chris



Sylvain Wallez wrote:

Hi all,

Investingating in the fancy uses that can be made of continuations, I 
was reading again the RhinoWithContinuations page on the wiki [1], and 
I felt confused by an example in that page :

function someFunction()  {
var kont  = new  Continuation();
print("captured: " + kont);
return kont;
 }
 var k = someFunction();
 if (k instanceof Continuation) {
print("k is a continuation");
k(200);
 } else {
print("k is now a " + typeof(k));
 }
 print(k);
Whose result is :
 captured: [object Continuation]
 k is a continuation
 k is now a number
 200
Why is "captured: [...]" printed only once, even if located _after_ 
the "new Continuation()" statement which I supposed to take the 
snapshot of the current execution state ?

The anwser is (Chris, please confirm or correct me if this is wrong) 
that "new Continuation()" doesn't take a snapshot of the exact 
location of the statement, but a snapshot of the closest function 
call, i.e. "someFunction()" in that case. And when the continuation is 
called using "k(200)", execution restarts at the location where 
someFunction() was called, with the new "200" result. Thus why we 
don't see "captured: [...]" twice.

So the granularity of a continuation is the _function call_, and not 
the statement.

Consider now this :
 function someFunction() {
 var kont1 = new Continuation();
 print("captured 1");
 var kont2 = new Continuation();
 print("captured 2");
 return kont1; // or kont2 !!
 }
Returning kont1 or kont2 doesn't matter, as the execution will restart 
at the call point of someFunction(). Confusing...

Digging further on continuations, I found an interesting comment to a 
weblog [2], where the guy proposes to extend the "arguments" object to 
hold the continuation associated to a function, i.e. replace :
   var kont = new Continuation();
by :
   var kont = arguments.continuation;

IMO, this syntax removes the confusion outlined above, since it 
unambiguously attaches the continuation to the current function call, 
and thus matches better the actual granularity of a continuation.

What do you think ? Would it be difficult to implement it that way ?

Sylvain

[1] http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations
[2] http://lambda.weblogs.com/discuss/msgReader$8089#8093

Re: Woody Event handlers are isolated !

[Ramy Mamdouh]

Hello Sylvain,

Sylvain Wallez wrote:
Ramy Mamdouh wrote:

Hello,

The new woody event handling looks really promising, but I'm concerned 
with the listeners being isolated from the rest of the application.

Is there any way we can provide the listeners with, say, the 
ServiceManager and some logger (the avalon life cycle stuff maybe)?

or maybe with the 'cocoon' object that's available from the javascript?

What do you think about this issue? 


That's exactly what I plan to do now ;-)

I want to introduce in Woody the pattern I used in the TreeProcessor : 
each widget definition and each listener will go through the Avalon 
lifecycle.
That's exactly what I dreamed to see, and it will be really cool :-)
Thanks a lot for your great efforts.
For JavaScript listeners, the I'd like to provide the "cocoon" object, 
with the exception that sendPage() and sendPageAndWait() won't be 
available. And if the form is called by a flowscript, also make the 
global variables (i.e. the session scope) available.

Sylvain

--
Ramy Mamdouh Kamel
[EMAIL PROTECTED]

Re: Woody Event handlers are isolated !

[Sylvain Wallez]

Ramy Mamdouh wrote:

Hello,

The new woody event handling looks really promising, but I'm concerned 
with the listeners being isolated from the rest of the application.

Is there any way we can provide the listeners with, say, the 
ServiceManager and some logger (the avalon life cycle stuff maybe)?

or maybe with the 'cocoon' object that's available from the javascript?

What do you think about this issue? 


That's exactly what I plan to do now ;-)

I want to introduce in Woody the pattern I used in the TreeProcessor : 
each widget definition and each listener will go through the Avalon 
lifecycle.

For JavaScript listeners, the I'd like to provide the "cocoon" object, 
with the exception that sendPage() and sendPageAndWait() won't be 
available. And if the form is called by a flowscript, also make the 
global variables (i.e. the session scope) available.

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: on better release and version management

[Giacomo Pati]

On Thu, 25 Sep 2003, Berin Loritsch wrote:

> Stefano Mazzocchi wrote:
>
> >>>
> >>> Contrast that with the parts that were ported over to use Maven, or
> >>> the GUIApp
> >>> project (http://d-haven.org).  A world of difference.  No longer is
> >>> there any
> >>> question about what is needed where.  No longer is there a need to
> >>> have JARs
> >>> locally in the repository.  No longer is there a need to have a 13 MB
> >>> download
> >>> for a full distributable.  Not to mention, it makes it easier to find
> >>> out what
> >>> exactly is a dependency and what is dead weight.
> >>
> >>
> >> seconded!
> >
> >
> > are you (or Berin) volunteering? [again, not caustic, just curious]
>
> :O WHat me volunteer?
>
> Maybe I should learn to keep my mouth shut.  ;P
>
> Seriously though, between Giacomo and I the build infrastructure would
> not be too hard to set up.  In fact, we can get it started in parallel
> to what is currently there.  When all are satisfied with the results,
> we remove the old build system.

I'd suggest to build up the new repo (if we go the Maven way) step by
step with a clear modularisation (read individual releasable units) in
mind and sketched out in a discussion here. I can think of someone (this
includes me, of course) starts moving class by class with the help of an
IDE like Eclipse that helps identifing the missing part until a module
is compilable.

> So when and where do we start on 2.2?  (As I asked before with Fortress
> integration)

Good question :-)

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Woody Event handlers are isolated ! (was: Re: Remove FormHandler? )

[Ramy Mamdouh]

Hello,

The new woody event handling looks really promising, but I'm concerned 
with the listeners being isolated from the rest of the application.

Is there any way we can provide the listeners with, say, the 
ServiceManager and some logger (the avalon life cycle stuff maybe)?

or maybe with the 'cocoon' object that's available from the javascript?

What do you think about this issue?

Thanks in advance.

Ramy

Sylvain Wallez wrote:
Marc Portier wrote:

Carsten,

Fixed, and committing...

Motivation: Thx to the woody-event changes from Sylvain this sample 
can in fact remove all references to the (now old)FormHandler.


Yep. +1 !!

on a related matter:
I really would remove the class alltogether as it would trigger 
additional compile errors maybe in early adopters' apps resulting in 
people changing to the new way of event-handling sooner rather then 
later. (already pre 2.1.2 that is :-)) 


I left FormHandler for the sake of compatibility, but I agree that it 
should be removed ASAP if we agree that this is no more the way to go.

Or if this triggers an avalance of "Hey this and that isn't working 
any more" -mails then it might even yield the use-case(s) (see 
code-comments) we are looking for ;-) 


Do you mean knowing what people use FormHandler for, giving us some 
input to define some new reactive widgets such as  ?

Sylvain

--
Ramy Mamdouh Kamel
[EMAIL PROTECTED]

[Vote] Build infrastructure (was: on better release and version management)

[Giacomo Pati]

On Thu, 25 Sep 2003, Stefano Mazzocchi wrote:
> On Thursday, Sep 25, 2003, at 10:47 Europe/Rome, Giacomo Pati wrote:
>
> > On Wed, 24 Sep 2003, Berin Loritsch wrote:

discussion on build infrastructure

> >>
> >> We tried to have a unified build system with ANT, and all excalibur
> >> projects
> >> re-using part of the central build file, etc.  NIGHTMARE CITY.
> >>
> >> Contrast that with the parts that were ported over to use Maven, or
> >> the GUIApp
> >> project (http://d-haven.org).  A world of difference.  No longer is
> >> there any
> >> question about what is needed where.  No longer is there a need to
> >> have JARs
> >> locally in the repository.  No longer is there a need to have a 13 MB
> >> download
> >> for a full distributable.  Not to mention, it makes it easier to find
> >> out what
> >> exactly is a dependency and what is dead weight.
> >
> > seconded!
>
> are you (or Berin) volunteering? [again, not caustic, just curious]

Well, as my time permits it and Berin could give a hand as well, why
not.

But first we need to come to a consensus about which build
infrastructure we would support to use:

1) Ant
 in this case we can use the current build system and tune it to the
 needs we have for the 2.2 and maybe add some ruper task to get rid
 of jars in our repository (suggested by Nicola Ken IIRC) and some
 more for modularisation ease

2) Centipede
 in this case I could not volunteer as I'm out of Centipede since
 their move from Cents to Antlibs (we still have some customer
 project using a Cents based version of it but they will never move
 to Antlibs)

3) Maven
 ATM this is my preferred build infrastructure and I could help
 building the 2.2 repo based on it

Please show your preferences (if you don't have a clue about Maven
and/or Centipede have a look at their sites at http://maven.apache.org
and http://www.krysalis.org/centipede/ respectively)

--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com

Re: Event handling in Woody

[Sylvain Wallez]

Andreas Hochsteger wrote:

Hi Sylvain!

Sylvain Wallez wrote:



I solved points 3&4 as follows :
-  are considered as "intra-form" actions : they never 
validate and always redisplay the form
-  (new widget that extends action) are considered as 
"form-exit" actions. They have an additional "validate" attribute 
that define if form validation should occur (true by default). For 
example, this allows a "cancel" button to be written as 


Would it be possible (perhaps in the future) to handle those 
intra-form actions completely on the client (eg. via JavaScript)?
Imagine using some DHTML to add or delete rows...

Not that I'd need it right now, but I'm just curious, if you thought 
about something like that.


Yes, I thought about that, and I even wrote some add/remove stuff for 
XMLForm before switching to Woody. But this can be very tricky to do as 
it highly depends on how the form widgets map to HTML code.

And since this mapping is defined by the form template, you can't rely 
on the fact that a repeater is laid out in a particular way. This could 
be done, however, if the layout of a repeater was templated using a new 
instance-only widget like the wi:group defined in "woody-page-styling.xsl".

Now the repeaters are only a small part of event-handling, as actions 
can be used to do many other things such as getting the (parsed and 
validated) value of other fields, accessing application data, etc. This 
server-side event handling allow to simply define complex form 
interactions at the cost of a roundtrip to the server. I'm currenlty 
investingating in moving form styling on XSL-enabled clients (Mozilla 
and IE6) which would speed up this rountripping.

Now handlers involving widgets only (and not app-data) may be sent to 
the client, but this would require to reconsitute an equivalent of the 
form model on the client. Not easy, but I'm not a client-side JS 
expert... Want to give it a try ?

Sylvain

--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

The granularity of continuations

[Sylvain Wallez]

Hi all,

Investingating in the fancy uses that can be made of continuations, I 
was reading again the RhinoWithContinuations page on the wiki [1], and I 
felt confused by an example in that page :

function someFunction()  {
var kont  = new  Continuation();
print("captured: " + kont);
return kont;
 }
 var k = someFunction();
 if (k instanceof Continuation) {
print("k is a continuation");
k(200);
 } else {
print("k is now a " + typeof(k));
 }
 print(k);
Whose result is :
 captured: [object Continuation]
 k is a continuation
 k is now a number
 200
Why is "captured: [...]" printed only once, even if located _after_ the 
"new Continuation()" statement which I supposed to take the snapshot of 
the current execution state ?

The anwser is (Chris, please confirm or correct me if this is wrong) 
that "new Continuation()" doesn't take a snapshot of the exact location 
of the statement, but a snapshot of the closest function call, i.e. 
"someFunction()" in that case. And when the continuation is called using 
"k(200)", execution restarts at the location where someFunction() was 
called, with the new "200" result. Thus why we don't see "captured: 
[...]" twice.

So the granularity of a continuation is the _function call_, and not the 
statement.

Consider now this :
 function someFunction() {
 var kont1 = new Continuation();
 print("captured 1");
 var kont2 = new Continuation();
 print("captured 2");
 return kont1; // or kont2 !!
 }
Returning kont1 or kont2 doesn't matter, as the execution will restart 
at the call point of someFunction(). Confusing...

Digging further on continuations, I found an interesting comment to a 
weblog [2], where the guy proposes to extend the "arguments" object to 
hold the continuation associated to a function, i.e. replace :
   var kont = new Continuation();
by :
   var kont = arguments.continuation;

IMO, this syntax removes the confusion outlined above, since it 
unambiguously attaches the continuation to the current function call, 
and thus matches better the actual granularity of a continuation.

What do you think ? Would it be difficult to implement it that way ?

Sylvain

[1] http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations
[2] http://lambda.weblogs.com/discuss/msgReader$8089#8093
--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com

Re: Event handling in Woody

[Andreas Hochsteger]

Hi Sylvain!

Sylvain Wallez wrote:



I solved points 3&4 as follows :
-  are considered as "intra-form" actions : they never 
validate and always redisplay the form
-  (new widget that extends action) are considered as 
"form-exit" actions. They have an additional "validate" attribute that 
define if form validation should occur (true by default). For example, 
this allows a "cancel" button to be written as 
Would it be possible (perhaps in the future) to handle those intra-form 
actions completely on the client (eg. via JavaScript)?
Imagine using some DHTML to add or delete rows...

Not that I'd need it right now, but I'm just curious, if you thought 
about something like that.

Bye,

	Andreas

[RT] Performance Block

[Reinhard Poetz]

If I present Cocoon I'm always asked three questions:

 - Is it stable?
 - Is it easy to integrate it into my environment?
 - Does it perform well?

I don't have problems to answer question one and two - Cocoon has been
stable for years and there is always an easy way to integrate it in
existing environments.

But I find it more difficult to give an answer on question three. In my
projects performance issues have always been solved but this information
is not very helpful if somebody evaluates Cocoon.

To come up with any performance figures is not difficult - however to
provide meaningful, standardized statistics much more. 


Proposal


I know it's not possible to provide the "definite truth" on the
performance of any technology and sometimes it's really funny to read
performance reports (e.g. J2EE Petstore vs .NET Petstore, or my database
is faster than yours ...) but it should be possible to give people an
idea in which *dimension* Cocoon can compete, not more. 
(I'm not afraid that Cocoon can't compete with compareable technologies
but I don't want a comparision of apples with oranges like the already
mentioned Petstore story where Sun's example wants to show patterns and
M$ has optimized it on speed. I could do the same with Cocoon if I
generate HTML with my JXTemplates without any further transformations ;)
)

Following all those considerations I want to propose the creation of a
new "performance" block that is ready to use for load tests - it should
contain:

 - one or more sample applications following Cocoon design patterns
 - performance optimized Cocoon configuration
 - JMeter integration
 - new Ant build target that creates all necessary things
   to run a test within the user's environment:
   * container (Jetty)
   * application
   * JMeter including the test script
   

 ... and the user can enter 
 - how much memory he wants to provide for the test
 - the number of concurrent users
 - the duration 
 and the cocoon.xconf, the various pool sizes and the settings 
 for the JVM are set accordingly.


What is this performance block good for?


 - We have an answer for the many performance questions.
 - Cocoon users will get a first impression on the performance
   of Cocoon in *their* environments
 - We can compare different Cocoon versions with each other!
   (e.g. we will see the performance improvements the Fortress
migration will bring in 'ms' ;) )
 - We may find problems that only appear under high load.


What would be reasons against this block?
-

 - We open the door for "apples to organges" comparisons.
 - This test can't use all the possible performance optimizations
   that are not part of Cocoon itself (caches like squid, OS
   specific things, ...)

Comments? (Up to now not a sinlge line of code has been writen - 
at least not by me ...)

Cheers,
Reinhard

Bug report for Cocoon 2 [2003/09/28]

[bugzilla]

+---+
| Bugzilla Bug ID   |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned|
| | OPN=ReopenedVER=Verified(Skipped Closed/Resolved)   |
| |   +-+
| |   | Severity: BLK=Blocker CRI=CriticalMAJ=Major |
| |   |   MIN=Minor   NOR=Normal  ENH=Enhancement   |
| |   |   +-+
| |   |   | Date Posted |
| |   |   |  +--+
| |   |   |  | Description  |
| |   |   |  |  |
| 4641|Opn|Nor|2001-11-05|Design of Source interface precludes implementatio|
| 5978|Ass|Nor|2002-01-23|Java SecurityManager java.lang.RuntimePermission c|
| 6200|New|Maj|2002-02-03|Parser failure with validate=true when processing |
| 7952|New|Nor|2002-04-11|No 'Last-Modified' header in the HTTP response|
| 8734|New|Maj|2002-05-02|ESQL Error in Cocoon 2.0.3-branch |
| 8948|Opn|Nor|2002-05-09|cannot call getOutputStream() after getWriter()   |
| 9538|Opn|Maj|2002-05-31|CachingOutputStream doesn't handle severed connect|
| 9728|New|Nor|2002-06-09|[PATCH] CocoonServlet getClassPath() enhancements |
| 9916|New|Enh|2002-06-17|javax.xml.transform.Transformer accepts object par|
|10203|New|Nor|2002-06-25|Docs referenced by XSLT's document() are not inclu|
|10208|Ass|Nor|2002-06-25|[PATCH]/[RT] Aggregation and Error Conditions (fil|
|10277|Ass|Nor|2002-06-27|Cannot set MIME type for ResourceReader   |
|10473|New|Nor|2002-07-04|Adding your own builtin-logicsheets does not work |
|10827|New|Nor|2002-07-15|ESQL  doesn't support namespaces|
|11716|New|Nor|2002-08-15| is formatting sensitive   |
|11962|Opn|Enh|2002-08-23|DigesterTransformer donation  |
|12158|Ass|Nor|2002-08-29|some improvements to Main.java|
|12562|New|Nor|2002-09-12|handle-errors skipped after first transformation  |
|12993|New|Enh|2002-09-25|[PATCH] New version of CastorTransformer (includes|
|13329|Opn|Nor|2002-10-05|merge XIncludeTransformer and CIncludeTransformer |
|13479|New|Maj|2002-10-10|Cocoon fails to compile sitemap and XSP in JBoss 3|
|13904|New|Nor|2002-10-23|FilterTransformer: ArrayIndexOutOfBounds exception|
|14074|New|Nor|2002-10-29|Previously reported tar bug - isn't (well, it is b|
|14144|New|Nor|2002-10-31|[Patch] add CompressionFilter declaration to web.x|
|14314|New|Enh|2002-11-06|Support for JDBC Array in SQLTransformer  |
|14327|New|Nor|2002-11-07|JSPReader: make the output encoding configurable. |
|14745|New|Enh|2002-11-21|[RFE] let serializer use request parameters   |
|14845|New|Enh|2002-11-26|[PATCH] Patch to generate a key with new resources|
|15100|New|Enh|2002-12-05|[patch]/[donation] Sample app xml form popup with |
|15150|New|Enh|2002-12-06|[PATCH]: HSSFSerializer Support for Gnumeric Merge|
|15220|New|Nor|2002-12-10|xsp pre-compilation : java sources and classes are|
|15302|Ass|Nor|2002-12-12|XSPUtil.relativeFilename() returns differents resu|
|15316|New|Nor|2002-12-12|FOP does not resolve relative paths   |
|15558|New|Enh|2002-12-20|IMAPGenerator Contribution|
|15614|Opn|Min|2002-12-22|Some documentation is inaccurate by version   |
|15841|New|Nor|2003-01-07|xsp:attribute handled incorrectly |
|15843|New|Cri|2003-01-07|EmptyStackException in EnvironmentStack   |
|15990|New|Enh|2003-01-11|Cocoon command-line should examine file timestamps|
|16101|Ass|Maj|2003-01-15|Cocoon website is not valid HTML  |
|16404|Unc|Maj|2003-01-24|flow script - local vars shared on different conti|
|16537|New|Nor|2003-01-29|[PATCH] fixed redirect under JRun 3.1 |
|16545|New|Min|2003-01-29|Logicsheet embedded in used-defined logicsheet doe|
|16710|New|Maj|2003-02-03|SQLTransformer.Query.serializeRow forces lower cas|
|16718|New|Enh|2003-02-03|[PATCH] Using only one connection in SQLTransforme|
|16958|New|Blk|2003-02-11|caching pipeline serves wrong content |
|17063|New|Nor|2003-02-13|[PATCH] XSP Request docs, demo out of sync with lo|
|17370|New|Nor|2003-02-25|Wrong HTTP Content Length for Reader when "show-ti|
|17593|New|Enh|2003-03-03|Allow to pass additional parameters to Flow+XMLFor|
|17594|New|Nor|2003-03-03|WebSphere redirect bug|
|17771|New|Nor|2003-03-07|[PATCH] new logging category never set when using |
|17924|New|Nor|2003-03-12|Cached resources don't have Expires-Header|
|17984|New|Enh|2003-03-14|SQLTransfo

Talk by TBL

[Jeremy Quinn]

Hi All

There is a talk by Tim Berners-Lee at The Royal Society:

	

"The Future of the World Wide Web".

enjoy

regards Jeremy

Re: cvs commit: cocoon-2.1/src/blocks/linotype/samples/scripts editor.js

[Geoff Howard]

[EMAIL PROTECTED] wrote:

ghoward 2003/09/28 04:54:24

  Modified:src/blocks/linotype/samples/stylesheets news2edit.xslt
   src/blocks/linotype/samples/scripts editor.js
  Log:
  Add initial IE support to linotype.  Changes were very complicated due 
  to revision mismatch, rejected hunks, and large number of changes.  
  Cleaning up still is needed.
As you may have noticed in the buzilla notice this commit was largely 
due to Klaus Bertram in a patch posted at 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22813.

DISCLAIMER: It was a bear to get this working and the committed version 
has some unnecessary changes, formatting issues, etc. There are probably 
cleaner ways to implement this crossbrowser support but I don't yet have 
my head around linotype enough to implement them at this point.

Please re-test linotype on Moz and/or IE.  I did of course but I'm sure 
you'll find stuff I didn't. :P

Geoff

DO NOT REPLY [Bug 22813] - [PATCH] Linotype for IE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22813

[PATCH]  Linotype for IE

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-09-28 11:59 ---
Ok, manually worked through the patches and resolved some remaining issues.  
Please test.  I accidentally sent the commit message before adding in credit to 
you, Klaus -- sorry about that.  I'll mention you and this bug entry in a 
follow up to the dev list.