from:"Stefano Mazzocchi"

Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Antonio Gallardo wrote:

Stefano Mazzocchi dijo:

Gump wrote:

cocoon-block-proxy-compile:
  [javac] Compiling 4 source files to
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
  [javac]
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
cannot resolve symbol
  [javac] symbol  : method getRequestBodyAsString ()
  [javac] location: class
org.apache.commons.httpclient.methods.PostMethod
  [javac] String body = ((PostMethod)
this.method).getRequestBodyAsString();
  [javac]   ^
  [javac] 1 error
I don't know how to fix this one from the gump side, it needs some code
changes since httpclient change a lot since this code was created.
Any ideas?

I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent.
They
are changing a lot in the new 3.0.x release. If we want gump compile
this
block, we need to add a dependency to our own distributed jar version
2.0.2.
I know this is a hack. The other way is to see more in depth and find a
way to compile code using both httpclient 2.0.2 and 3.0 too.
WDYT?
That build is against the 2.0.x branch.

Its posible in the CVS version.
In the javadocs for release 2.0.2, the PostMethod. Because is direct
derived from EntityEnclosingMethod:
http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/methods/PostMethod.html
Now go to the CVS. in the HTTPCLIENT_2_0_BRANCH We still see the
method getRequestBodyAsString() inside:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/methods/EntityEnclosingMethod.java?rev=1.18.2.5&only_with_tag=HTTPCLIENT_2_0_BRANCH&view=markup
...
I am not a CVS guru, but in the HEAD (3.0 release) there is not the method.
Seems like they broke a contract? I mean removing a method without
deprecate it first?
yeah, they did, but what I don't  understand is why we didn't build 
against HTTPCLIENT_2_0_BRANCH.

puzzled.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
Gump wrote:

cocoon-block-proxy-compile:
   [javac] Compiling 4 source files to
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
   [javac]
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
cannot resolve symbol
   [javac] symbol  : method getRequestBodyAsString ()
   [javac] location: class
org.apache.commons.httpclient.methods.PostMethod
   [javac] String body = ((PostMethod)
this.method).getRequestBodyAsString();
   [javac]   ^
   [javac] 1 error
I don't know how to fix this one from the gump side, it needs some code
changes since httpclient change a lot since this code was created.
Any ideas?

I saw the code of httpclient 2.0.x and 3.0 and it is quite diferent. They
are changing a lot in the new 3.0.x release. If we want gump compile this
block, we need to add a dependency to our own distributed jar version
2.0.2.
I know this is a hack. The other way is to see more in depth and find a
way to compile code using both httpclient 2.0.2 and 3.0 too.
WDYT?
That build is against the 2.0.x branch.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GUMP@brutus]: Project cocoon-block-mail (in module cocoon) failed

Gump wrote:
cocoon-block-asciiart-compile:
cocoon-block-velocity-compile:
cocoon-block-cron-compile:
cocoon-block-batik-compile:
cocoon-block-xsp-compile:
cocoon-block-forms-compile:
cocoon-block-databases-compile:
main:
cocoon-block-ojb-compile:
this is very weird. the 'mail' block does not depend on ojb, so why is 
the cocoon build system trying to build it?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GUMP@brutus]: Project cocoon-block-proxy (in module cocoon) failed

Gump wrote:
cocoon-block-proxy-compile:
[javac] Compiling 4 source files to 
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-02112004/blocks/proxy/dest
[javac] 
/home/gump/workspaces2/public/workspace/cocoon/src/blocks/proxy/java/org/apache/cocoon/generation/HttpProxyGenerator.java:294:
 cannot resolve symbol
[javac] symbol  : method getRequestBodyAsString ()
[javac] location: class org.apache.commons.httpclient.methods.PostMethod
[javac] String body = ((PostMethod) 
this.method).getRequestBodyAsString();
[javac]   ^
[javac] 1 error
I don't know how to fix this one from the gump side, it needs some code 
changes since httpclient change a lot since this code was created.

Any ideas?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Switching rhino implementation

2004-11-01 Thread Stefano Mazzocchi

Reinhard Poetz wrote:
I'm going to integrate the new Rhino+cont implementation in the next few 
days and plan to support the old and the new implementation, at least in 
2.1. I wonder ...
Jesus, what happened to the release early and often paradigm? 2.1.6 has 
been in the making forever. Can we get that sucker out of the 
door or we have to fix all the bugs before we do? and that will never 
happen anyway.

shrug.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GUMP@brutus]: Project cocoon-block-xsp (in module cocoon) failed

2004-11-01 Thread Stefano Mazzocchi

Antonio Gallardo wrote:
Stefano Mazzocchi dijo:
This is very weird: instead of executing the 'xsp' block, it runs the
'paranoid' block. This is not a gump problem.
Do you people have any idea of what's going on?

Yep! We know! :-D
See this:

org.apache.cocoon

  
I will fix it now. ;-)
Awesome, thanks a lot!
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [GUMP@brutus]: Project cocoon-block-xsp (in module cocoon) failed

2004-10-31 Thread Stefano Mazzocchi

Gump wrote:
Project cocoon-block-xsp has an issue affecting its community integration.
This issue affects 26 projects.
[...]
gump-block:
cocoon-block-paranoid:
cocoon-block-paranoid-prepare:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-31102004/blocks/paranoid/dest
cocoon-block-paranoid-compile:
[javac] Compiling 3 source files to 
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-31102004/blocks/paranoid/dest
  [jar] Building jar: 
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-31102004/blocks/paranoid-block.jar
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/cocoon/build/cocoon-31102004/blocks/paranoid/samples
cocoon-block-paranoid-tests:
This is very weird: instead of executing the 'xsp' block, it runs the 
'paranoid' block. This is not a gump problem.

Do you people have any idea of what's going on?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Heads up] Change to build system in 2.1.x

2004-10-30 Thread Stefano Mazzocchi

Ugo Cei wrote:
Il giorno 25/ott/04, alle 19:14, Unico Hommes ha scritto:
I've completed the changes to the build system discussed earlier [1]. 
In order to do so I have extended the gump descriptor with additional 
information that allows the build system to locate one or more 
dependency jars per  project within ./lib/optional. See for an 
example the cocoon-block-axis project definition in gump.xml

Every block now *must* declare all the dependencies it requires to 
compile in gump.xml just in order for it to build properly.

Looks like this is not a backward-compatible change. Blocks which are 
distributed outside of Cocoon (like Fins or my Spring Petstore) must 
change their deployment instructions to add all those  elements 
(and put dependencies in gump too, which wasn't required before, even 
though it might have been good practice).

Shouldn't we make this change in trunk only and leave 2.1 as is?
yes, this is a pretty big obstacle for a simple bugfix release. The 
block build system *is* not an aPI but it's a contract and we must honor 
them.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Proposal] New Block building system

Reinhard Pÿfff6tz wrote:
 --- Stefano Mazzocchi <[EMAIL PROTECTED]> schrieb: 

Reinhard Poetz wrote:
Stefano Mazzocchi wrote:

Reinhard Poetz wrote:

More information and explanations can be found
at 

http://wiki.apache.org/cocoon/CocoonBlockBuilder

[not critizing, just curious] can you explain why
you think that 

having block/lib is going to be jar hell while
lib/block is not?
I would really like to see block/lib instead of
lib/block but without 

Pier's shielding classloader I don't see how we do
NOT end in jar 

versioning hell.
Good point.
+1 to your choice.

I think it can provide a smooth transition from
current blocks to RealBlocks and the work can be done
in incremental steps.
Agreed.
Stefano and others, What do you think, should I
continue with the new block build system?
Go right ahead.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Implementation of the Continuations checker

Vadim Gritsenko wrote:
Nicola Ken Barozzi wrote:
Unico Hommes wrote:
...
I believe that the excalibur event package lives on at d-haven [1]. 
Why not use that?

Or we could stick with excalibur-event, if there is nothing wrong with it.

Oh oh. We did this discussion with the container, I hope we don't have 
to go over this again for every Avalon dependency we have ;-P

This smells a lot as NIH syndrome [1]. Are we going to rewrite every 
single excalibur component we use?
Potentially, yes. It's a small price to pay to gain solidity of your 
foundations.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Implementation of the Continuations checker

Unico Hommes wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
Giacomo Pati wrote:
On Fri, 29 Oct 2004, Carsten Ziegeler wrote:
The current implementation of our continuations manager uses the
excalibur event package for the background checker that checks for
expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't using it somewhere else,

so it would
be great if we could remove this dependency.
Yesterday, I wrote a simple replacement which I checked into 2.2:
a simple background thread is initialized that sleeps for a

configured
period of time, checks the continuations, sleeps etc.
Now, this solution should work.
The question is now, should I port this to 2.1.x as well? Are there
better solutions?

Does this mean the CommandManager from the Context is gone?
Yes, at least for 2.2 - for 2.1.x we would have to decide if we 
remove it.

Are you using it?

Yes, we used the CommandManager in some projects. It is based on the 
PooledExecutor from Doug Leas concurrent-utils package. It comes in 
quite handy as you can put tasks there you'd like to be done 
asynchroniously (ie. indexing a uploaded document with lucene to speed 
up percieved performance).

I believe that the excalibur event package lives on at d-haven [1]. Why 
not use that?

1. http://api.d-haven.org/event/
because, with all due respect to Berin, this is another one man show and 
we are sick of having them change under our feet.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] StringTemplate: The answer to our templating needs?

Bart Molenkamp wrote:

-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
Sent: Friday, October 29, 2004 10:47 AM
To: [EMAIL PROTECTED]
Subject: RE: [RT] StringTemplate: The answer to our templating needs?
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the code
is hard to understand and having all classes in a single huge
source code file does not help.
Yupp, that is one of the problems with JXTG. It would be great if
a new solution would be pluggable to add new "tag libs" as well.

Making it pluggable may also have the disadvantage that languages are
added that can give more control than required for presentation of data.
This can make the separation of concerns less clear, which is IMO one of
the great things in Cocoon (the control flow). Templates may look like
XSP pages, or similair (code mixed with content), breaking the SoC.
Or am I wrong?
no, you are totally right.
People, all we need is a way to connect to objects. And we need only one 
and the less the language is functional, the better.

--
Stefano.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: Implementation of the Continuations checker

Bart Molenkamp wrote:
Maybe CRON can handle this job? Or isn't it a good idea to have the core
of Cocoon depent on CRON?
unfortunately, CRON is not a portable service across OS and we do 
support silly microsoft OSs too.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] StringTemplate: The answer to our templating needs?

Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
I don't think JXTG is broken now, it works well but the code 
is hard to understand and having all classes in a single huge 
source code file does not help.

Yupp, that is one of the problems with JXTG. It would be great if
a new solution would be pluggable to add new "tag libs" as well.
I created a long time ago the TemplateObjectModelHelper which is 
in the scratchpad area. The idea of this class is to provide one
single object model that can be used in various components,
like a template generator/transformer, input moduls, java code etc.
In the end, regardless where you want to access objects (flow,
template stuff, input modules) you always use the same way, like
"cocoon.request" etc. Depending on the language the component
provides the syntax may vary, like "cocoon/request" - but the path
you use is always the same.
I like!
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)

Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
 

XPath is a must-have when you deal with XML documents while Jexl is 
mostly useless in that case but is straightforward when you deal with 
JavaBeans. I also agree that understanding the difference between 
"${continuation.id}" and "#{$continuation/id}" is less than evident.

So what about a unified syntax for expansion tokens, within which 
different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]

  
Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
 

Agree, but considering the wide variety of applications contexts where 
Cocoon is used, I don't think there can be a single "one-size-fits-all" 
language.

There are also a number of places in Cocoon where we need to evaluate 
expressions: templates, sitemap, form validators, form bindings, etc, 
which are currently implemented separately with different syntaxes. We 
need a common expression evaluation component.

So, let's decide on one language that we think is the best, but
let's provide a hook so others can plugin their language if *they*
want to.
 

That's exactly what I suggest above: we choose a standard default 
language, but open the possibility to plug in new ones. XPath is a 
must-have, Jexl and IM have very valid use cases which IMO justify them 
to be provided by Cocoon. Other languages are just a possibility that we 
offer _if_ people want to add their own language.
Excuse my ignorance, but can you outline the pro/cons of each path 
language, along with what it can't be done with it that can be done with 
others?

I guess that would be helpful for people to decide.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] StringTemplate: The answer to our templating needs?

Carsten Ziegeler wrote:
Sylvain Wallez wrote:

XPath is a must-have when you deal with XML documents while 
Jexl is mostly useless in that case but is straightforward 
when you deal with JavaBeans. I also agree that understanding 
the difference between "${continuation.id}" and 
"#{$continuation/id}" is less than evident.

So what about a unified syntax for expansion tokens, within 
which different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]

Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
Amen. I wouldn't even go for plugins. Let's chose one syntax and just 
use that.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] StringTemplate: The answer to our templating needs?

Giacomo Pati wrote:
On Fri, 29 Oct 2004, Reinhard Poetz wrote:
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better 
templating system for Cocoon?  This is where I encourage people to 
dive in and give their own [RT]s and thoughts on the issue.

First, thank you for the pointer. Interesting stuff.
But first, we should agree on our needs and then we should choose a 
technology.
IMO less is more - the templating engine should really focus on 
presenting data. I see following needs:

- really powerful query language to access
* all kind of objects
* incl. passed DOM trees
- control structures like for/each, if, choose
- call methods on passed objects
- stream objects (DOM, XMLizable, ...?)
- and probably a way to define macros (see cForm macros)

Add this:
- works as a Transformer (SAX pipeline)
Don't know whether we need the possibilty to use xPath expressions on 
passed objects. On one hand it would be helpful, on the other we 
probably end again with two different syntax.

XPath is what we're used to when writing xslt stylesheets. The Java 
dotted notation is what we're used to when writing Java code. As the 
templating engine will most likely be some xml syntax XPath make IMHO 
much more sense to me than dottet notation.
May I remind you people of Pier's Garbage? He lost interest in it, but I 
personally like the approach very much.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Proposal] New Block building system

Reinhard Poetz wrote:
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
More information and explanations can be found at 
http://wiki.apache.org/cocoon/CocoonBlockBuilder

[not critizing, just curious] can you explain why you think that 
having block/lib is going to be jar hell while lib/block is not?

I would really like to see block/lib instead of lib/block but without 
Pier's shielding classloader I don't see how we do NOT end in jar 
versioning hell.
Good point.
+1 to your choice.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Proposal] New Block building system

2004-10-28 Thread Stefano Mazzocchi

Reinhard Poetz wrote:
More information and explanations can be found at 
http://wiki.apache.org/cocoon/CocoonBlockBuilder
[not critizing, just curious] can you explain why you think that having 
block/lib is going to be jar hell while lib/block is not?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Leszek Gawron and Ralph Goers as committers

2004-10-28 Thread Stefano Mazzocchi

Leszek Gawron wrote:
I thought there is still very much 
to do to prove myself useful and trustworthy.
... and that's exactly why everybody thinks you deserve committership ;-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Leszek Gawron and Ralph Goers as committers

2004-10-28 Thread Stefano Mazzocchi

Torsten Curdt wrote:
Folks please cast your votes for:
[  ] Leszek
[  ] Ralph
as Apache Cocoon committers.
+1
Welcome on board!
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

David Crossley wrote:
So when a real, potentially damaging, issue arises
we will have no way to sensibly handle it.
It has been working fine so far and I see no evidence of things changing.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

How to make things better

Luigi Bai wrote:
If you have ideas on how to make it better, we are wide open to 
suggestions.
Okay, assuming your sincerity - what is the current method for 
committers to find/fix/close issues in Bugzilla? 
there is no codified method. Basically, one those patches/fixes/bugs 
that are promoted by somebody that really cares (and really keeps 
bugging us) get in. The others remain in a limbo until somebody cares.

Are votes used, or longest time open, number of comments? 
we have cronned script that sends a list of unapplied patches to the 
mail list every sunday. it was a nice try but if everybody skips over it 
the way I do, it's pretty much useless.

currently, we have no way to "rank" the most important issues. I agree 
that would be a great addition. Something like "vote your issue" would 
go a long way to identify what things we can work on.

How often are these criteria 
applied (periodically, only FirstFriday, only before release)?

Knowing these, we can figure out a way to improve the system, or the 
users's expectations (or both!).
We tried to improve the system with FirstFriday. It was a nice try but I 
think it's not keeping up with the expectations.

The "bugathon" worked well for the past 2 years, but we need something 
more continous.

I like your suggestion of improving the 'ranking' of the pending issues, 
so that one doesn't feel overwhelmed without an indication of importance.

Of course, on the other hand, every ranking methodology might hide some 
of the issues even more.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

Luigi Bai wrote:
On Tue, 26 Oct 2004, Stefano Mazzocchi wrote:
forth: some of us spend a great amount of their life trying to come up 
with strategies that avoid the use of those rules, and understand how 
complex groups form and dissolve, how innovation happens and how 
community fractures can be avoided. When shit works well, like this 
project, it's easy to think it 'just happened' and much harder to see 
all the social work that made it possible, including allowing informal 
votes to happen and keeping rules to a bare minimum.

Maybe it is more precise to say "When shit works /mostly/ well...". The 
presence of a large number of outstanding Bugzilla issues, especially 
ones with [PATCH]es attached, implies that things work well for 
committers, less well for those of us who have to wait until "someone 
just gets around to it". Fixing bugs isn't sexy, like Flow or Forms or 
Real Blocks. But it should happen every once in a while, especially when 
other people have already proposed the patches.
If you have ideas on how to make it better, we are wide open to suggestions.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

I'm trying really really really hard not to reply to this but I can't.
Frédéric Glorieux wrote:
For computing, you are really incredible guys, but for politics, I'm 
sorry to say that but you are "reinventing the wheel". Rules are not 
"bureaucratic" but the only way to have a stable democracy, which is the 
less unefficient governement (for long periods).
first: we are not doing politics, not establishing a government, nor we 
believe in democratic development metodologies.

second: I've been around open source long enough to know that rules are 
necessary, *BUT* I've also seeing people that love rules more than the 
reason why they exist. Rules are not made to create cages, but 
guidelines. Our philosophy follows the Postel principle for internet 
architectural design: "be strict in what you send, be flexible in what 
you receive".

third: if there is one thing that the ASF never did was to "reinvent the 
wheel" in the labor collaboration and management space. Several business 
schools of the major universities of the world are studying how we 
managed to achive what we achieved. Some of them believe this is some of 
the most innovative critique of existing labor cooperation since Marx.

forth: some of us spend a great amount of their life trying to come up 
with strategies that avoid the use of those rules, and understand how 
complex groups form and dissolve, how innovation happens and how 
community fractures can be avoided. When shit works well, like this 
project, it's easy to think it 'just happened' and much harder to see 
all the social work that made it possible, including allowing informal 
votes to happen and keeping rules to a bare minimum.

Now, go back and re-read my comments under this light.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

Bertrand Delacretaz wrote:
Le 26 oct. 04, à 17:41, Stefano Mazzocchi a écrit :
..Bah, burocrats.

;-)
I see David's point though, using [VOTE] in subject (and [PROPOSAL] 
maybe) helps in not missing stuff that's happening.

But I like our +1 way of saying "me? I like it" even if outside of a 
vote - it's part of our "slang" I think.

So +1 on being more careful with [appropriate headers] in subjects ;-)
I hear you and I agree.
But one thing is saying "next time use [vote] so that people don't miss 
it", another is "start over and follow the rules".

The first is common sense, the second is burocracy.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

Tony Collen wrote:
Bertrand Delacretaz wrote:
+1, I agree with the formal vote but if you start it by counting all 
the +1s here we don't need to vote again.

Alright, well I guess I phrased my message as a pseudo-vote, so the 
confusion is my fault!

Anyway, I'l count the existing votes as if it were an official vote 
through Thursday night GMT.  If anybody who's already voted wants to 
change their mind in the meantime, go ahead (but it doesn't seem likely).

Here's my implicit +1, too.
Oh, c'mon, we have a gazillion +1 and no -1, go ahead and deprecate it.
It's not like we can't reverse the thing if a -1 shows up.
Bah, burocrats.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

David Crossley wrote:
No, it is not bureaucratic. It is about efficiency.
That's what bureaucrats always say ;-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Let's deprecate the PHP block

2004-10-25 Thread Stefano Mazzocchi

Tony Collen wrote:
To my knowledge, the PHPGenerator hasn't worked for quite some time.  In 
all the time I've been working with Cocoon, I have never seen it work 
correctly.

However, I believe the problem is within the PHP Servlet itself, which, 
if you do some research, tons of people have had problems with it being 
FUBAR for ages.

There are lots of messages from people looking to get it working on the 
lists as well:

cocoon-dev: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=phpgenerator&q=b
cocoon-users: 
http://marc.theaimsgroup.com/?l=xml-cocoon-users&w=2&r=1&s=phpgenerator&q=b

Here's a good example of recent attempt of using the PHP Servlet:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=107340894710274&w=2
It's my personal opinion that we'll never see a good PHP servlet, 
especially since it's been "in beta" for a number of years.

Let's deprecate the PHP block for the remainder of our 2.1.X releases 
and then dump it in 2.2.  If people want to "use" PHP with Cocoon, the 
best solution is to just use a FileGenerator and an http:// URL.
+1 nobody uses it anyway.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Heads up] Change to build system in 2.1.x

2004-10-25 Thread Stefano Mazzocchi

Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
We really gotta start thinking about our build system and gump 
integration.

Vadim Gritsenko wrote:
Unico Hommes wrote:
I've completed the changes to the build system discussed earlier 
[1]. In order to do so I have extended the gump descriptor with 
additional information that allows the build system to locate one or 
more dependency jars per  project within ./lib/optional. See 
for an example the cocoon-block-axis project definition in gump.xml

Every block now *must* declare all the dependencies it requires to 
compile in gump.xml just in order for it to build properly.

Since I am not very familiar with gump.xml and I had to add a lot of 
information it is very probable that I made a mistake or two with 
the way local projects are declared.

I thought you'll add  element which would be independent of 
 element and thus avoid any possible conflicts with Gump. 
But now I see that you'd added bunch of new  elements - 
which are not currently required by Gump - I don't think we should do 
that.

I'd sleep better if instead of:
+
+
+
+
We'd have:
+
+
+
+

this will make our descriptor being invalid, but since I control the 
DTDs we can change that on the other hand.

but there is something that bothers me: the above really doesn't make 
any sense. What would be a lot more useful would be something like

 
or
 
or
 
then it would be up to gump to give you the version you want (and we 
might indicate what versions we expose in our gump.xml description).

Two points;
 * Gump is about continuous integration, i.e. always trunk, right?
so far ;-)
   And our build does not need version information too. Then,
   who needs it?
My idea is the following: gump should be *both* a build system and a 
continous integration system. It should build your project in two phases:

 1) run against the dependencies with the versions you specify (since 
they will never change, they can be built once and their packages kept 
in place forever). If broken send nightly build error and stop.

 2) if nightly built was successful, perform continous integration by 
running against the latest and greatest. If broken, send continous 
integration warning and stop.

 * gump.xml currently does not record dependency on antlr. Do you think
   it should be added? 
yep.
Why? 
see above.
That's what I meant above - I'm not sure
   we should add bunch of dependencies.
Another issue is that dependency project name might not match library 
name...
well, that's your concern only if you specify the version (and, even in 
this case, it's enough to create a mapping between a version and a 
tag/timestamp).

If you specify a timestamp or a tag, gump can figure it out by itself 
since it has all the metadata it needs to figure out where the builds 
write their jars and how they name them.

Hope this helps.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Heads up] Change to build system in 2.1.x

2004-10-25 Thread Stefano Mazzocchi

We really gotta start thinking about our build system and gump integration.
Vadim Gritsenko wrote:
Unico Hommes wrote:
I've completed the changes to the build system discussed earlier [1]. 
In order to do so I have extended the gump descriptor with additional 
information that allows the build system to locate one or more 
dependency jars per  project within ./lib/optional. See for an 
example the cocoon-block-axis project definition in gump.xml

Every block now *must* declare all the dependencies it requires to 
compile in gump.xml just in order for it to build properly.

Since I am not very familiar with gump.xml and I had to add a lot of 
information it is very probable that I made a mistake or two with the 
way local projects are declared.

I thought you'll add  element which would be independent of 
 element and thus avoid any possible conflicts with Gump. But 
now I see that you'd added bunch of new  elements - which are 
not currently required by Gump - I don't think we should do that.

I'd sleep better if instead of:
+
+
+
+
We'd have:
+
+
+
+
this will make our descriptor being invalid, but since I control the 
DTDs we can change that on the other hand.

but there is something that bothers me: the above really doesn't make 
any sense. What would be a lot more useful would be something like

 
or
 
or
 
then it would be up to gump to give you the version you want (and we 
might indicate what versions we expose in our gump.xml description).

Thoughts?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Remove excalibur instrumentation support from 2.2

2004-10-24 Thread Stefano Mazzocchi

Carsten Ziegeler wrote:
Stefano Mazzocchi wrote: 

+1
Carsten, one thing, when you remove a dependency, please 
update the gump.xml descriptor too!

Sure, until now I only removed one jar (excalibur-testcase) and
I updated gump.xml as well. Just curious, did I forget it somewhere
or is this a general reminder?
nono, just a general reminder.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Remove excalibur instrumentation support from 2.2

2004-10-24 Thread Stefano Mazzocchi

Carsten Ziegeler wrote:
The ECM++ is now integrated in 2.2 and it seems that most things
are running again - even simple XSP pages (haven't tested more yet).
Now, as I mentioned earlier, one idea of ECM++ is to support only those
interfaces/features that we really need.
One candidate in this category is obviously the instrumentation
support - the current version of ECM++ doesn't support it.
I think we should remove the support for excalibur instrumentation
completly from our 2.2 code base, because:
- only one single class in our whole repository is using instrumentation
  (the continuation manager)
- instrumentation can be seen as a proprietary solution that noone else is
using
- when we will have real blocks we will need other instrumentation
mechanisms anyway as we don't want to depend on excalibur in this case. So
migrating earlier is better.
Now, don't get me wrong - excalibur instrumentation is really a nice
project.
In the end when we think of real blocks we need another solution anyways -
this could be JMX or something else, but it's most likely that it won't be
excalibur instrumentation. So, imho it's better to move sooner (with 2.2),
remove the
instrumentation code, add a different solution and start using that
throughout
Cocoon.
Cocoon is not really affected by the removal, it might only affect users
that are using the instrumentation for their applications. So these users
would have to migrate to whatever we build into 2.2 then. 

If the result of this vote is to support instrumentation in 2.2, the missing
code can be added to ECM++ without major problems.
So, please cast your votes on removing the support starting with 2.2:
+1
Carsten, one thing, when you remove a dependency, please update the 
gump.xml descriptor too!

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [cron block] dependency question

2004-10-22 Thread Stefano Mazzocchi

Giacomo Pati wrote:
The simplest possible thing would be to have a block descriptor extend 
a maven POM and use maven to build them.
Wow, you propose using maven?
apparently ;-)
blocks are very simple things and don't require special treatment so 
they could be built with maven easily. As for the whole thing, I'm still 
not sure.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [cron block] dependency question

Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Why? It is easier to write and maintain single ant script 
than 55! (we 

have 55 blocks right now)
Let me answer for Reinhard :-)
If every local buildfile has
  
then there is not really more to maintain, but you gain in 
being able to customize the build where needed and to build 
the block 'locally'. It also becomes easier to accomodate for 
extra external blocks that do not necessarily need only our 
build targets.

Hmm, to be honest this frightens me a little bit. I really hope
that we are not experiencing the "avalon build system problem"
where each module had his own build file with all this complex
library and dependency handling and the final result was that
noone was able to use the build system for months. Then going
back and force from Ant to Maven etc. which in the end didn't
really help.
But in the end I trust you and I guess *we* will not suffer from
these problems. Let's just try to keep it as simple as possible,
but working :)
The simplest possible thing would be to have a block descriptor extend a 
maven POM and use maven to build them.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question about the best way to locate the path to WEB-INF

Butler, Mark H (Labs Bristol) wrote:
Hi Stefano
Actually Patrick logged it as a server bug with the Apache Tomcat team,
but they weren't very impressed see 

http://issues.apache.org/bugzilla/show_bug.cgi?id=31806
I suspect its not so much a bug, more a feature of two different teams
interpreting the servlet specs differently :)
No, I think Remy just didn't get where the problem is (probably has to 
deal with a million of those faulty bug reports).

I suggest Patrick to start a discussion on tomcat-dev@ and, also, cut 
the stacktraces since they just add noise.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Question about the best way to locate the path to WEB-INF

Butler, Mark H (Labs Bristol) wrote:
Hi team,
I need your advice on the best way to fix a problem when using Cocoon on
Tomcat caused by DELI that I do not encounter when running Cocoon on
Jetty. Therefore I would like your advice as solving the problem seems
to require an understanding of the differences between servlet engines
that I'm afraid I do not possess. Patrick Melo has reported this
exception:
java.net.MalformedURLException: Path
\\server\share\webappname\webappname\WEB-INF/deli/config/deliConfig.xml
does not start with a "/" character
java.net.MalformedURLException: Path
\\server\share\webappname\webappname\WEB-INF/deli/config/deliConfig.xml
does not start with a "/" character
hmmm, it looks like a servlet container bug to me. Is the guy running 
this over an SMB remote disk? My guess would be that jetty normalizes 
the "/\" and maybe java doesn't complain there. Bah, I really don't 
know, your code looks fine to me.

--
Stefano, scratching head.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ECM++

Niclas Hedhman wrote:
On Thursday 21 October 2004 21:40, Stefano Mazzocchi wrote:
As for continous integration, Gump is your friend, so you should
not have to worry about that.
Provided we can get Gump all the way up and beyond Cocoon :o)
Soon there...
you can bet your ass we will! :-)
--
Stefano "Capt. Stubborn".


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Link Livesites: Cocoon 2.1.5

Upayavira wrote:
[EMAIL PROTECTED] wrote:
True! However, if there is a form to be filled in, some questions will be
answered beforehand, thus eliminating several mails back and forth.
Some of the questions: - how can I see that Cocoon was used?
- why did you use Cocoon? - how much time did the project take?
- how many members did the project team have?
 

Hi Helma,
You asked previously about what it would take for us to be able to run 
Cocoon on Apache hardware. At the moment, Apache has something like six 
machines, and these are guarded (quite rightly) fiercely by the 
intrastructure team, in order to keep them suitably secure.

There are a lot of projects that would like to have access to Apache 
hardware, whether for hosting, or for build/test cycles. In part, as a 
way to cater for this, the infrastructure team is building a couple of 
those machines to run VMWare ESX - thus they can host multiple operating 
systems on each machine. ESX is working, but they need to get more 
HDD/memory for it to handle more VMs. If we have needs for running our 
own stuff, e.g. having the latest Cocoon samples usable from the Cocoon 
website, we should make a request to the infrastructure team for a VM 
for ourselves, as soon as they have done the necessary hardware upgrades.

This would of course require us to choose an OS/distribution (never easy 
in a diverse community!) and then to maintain it.

Are people interested in pursuing this?
In the meantime, using our existing mechanisms, we should do as Antonio 
suggested - improve the notes on the livesites page, stating: Put an 
entry entitled [LINK] Blah into bugzilla, and answer these questions. If 
you don't answer them, your request will not be considered.

Or something like that. What do you think?
FYI, I have root access on brutus.apache.org (the machine that runs 
gump) and we could start to proxy_pass from cocoon.apache.org on to brutus.

The machine is a dual xeon, 4Gb of ram, SCSI disks, runs JDK 1.4.2 and 
has a MySQL database installed.

The machine is considered "not highly secure" by infra@ since it 
executes code that we don't control. If we can live with that low 
security, we can route around infra@ concerns and move on.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ECM++

Andreas Hartmann wrote:
Stefano Mazzocchi wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now


[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...

Andreas, I *strongly* suggest that you keep off until we are at least 
in beta state. Or, if you don't, I *even more strongly* suggest you 
that you don't complain if things change under your feet.

Alpha here means "contracts are unstable and rightly so".
You have been warned.
Thanks!
I replied on lenya-dev.
Obviously, the same applies to any other dependee until we reach beta 
state. As for continous integration, Gump is your friend, so you should 
not have to worry about that.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] applying SoC on cocoon itself

Tim Larson wrote:
On Wed, Oct 20, 2004 at 07:06:54PM +0200, Sylvain Wallez wrote:
Reinhard Poetz wrote:
Or another alternative
 
   
   ...
 

Typing parameters. That's *really* interesting. I prefer Reinhard's 
proposal which leaves room for future expansion to other types.

Should we use the string->typed-java-objects converters from CForms,
perhaps enhanced with a few new types such as URI/URL's?
NO!
God, I wonder, am I the only one that feels that you are fixing silly 
details and missing the problem entirely?

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] applying SoC on cocoon itself

Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Mmhh... what if other parameters are also URIs?

If src attribute to be interpreted always as a Source object... We 
could add map:source as well:

  




...
  
Vadim
Or another alternative
   
 
 ...
   
[sound of Stefano's FS alarms going off]
People, step back and think at the "global" problem not at the specific 
one, focusing on little details is not the way to do architectural design.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] applying SoC on cocoon itself

Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Mmhh... what if other parameters are also URIs?

If src attribute to be interpreted always as a Source object... We could 
add map:source as well:

  




...
  
[sound of stefano puking]
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] applying SoC on cocoon itself

Unico Hommes wrote:
I've often thought that the signature of the setup() method was wrong. 
The src parameter is passed as a String, the component is free to 
interpret it as anything it wishes. But I think this parameter was 
really only meant to ever be interpreted as a Source object. So instead 
of setup(SourceResolver resolver, Map om, String src, Parameters pars) 
the method should be setup(Source source, Map om, Parameters pars). That 
also unambiguously defines the meaning of the src attribute.
Amen. Too bad this is the most back-incompatible change you can think 
of. :-(

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ECM++

Sylvain Wallez wrote:
Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as 
possible and in general do all the big changes on branches.
Why do Lenya and Forrest use 2.2? The Cocoon stable branch is *2.1* and 
trunk is the *development branch*, where we can break things. Other 
branches are playgrounds for more revolutionizing works.
Exactly my perception.
We should put back that WARNING sign that we use on alpha trees.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ECM++

Nicola Ken Barozzi wrote:
Forrest is using 2.2 too, so let's try to keep it stable as much as 
possible and in general do all the big changes on branches.
Hmmm, I'm not sure if I like this.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ECM++

Ugo Cei wrote:
Il giorno 20/ott/04, alle 09:33, Carsten Ziegeler ha scritto:
Yes, it's stable now - the code could be optimized a little bit here
and there, but I would do this after we have the tests.
Are we targetting JDK 1.4 for this release? If so, can I change 
CascadingRuntimeException to RuntimeException?
+1 for targetting 1.4 for cocoon 2.2
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] applying SoC on cocoon itself

Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
 


Or maybe a good solution can be to combine both approaches: the 
sitemap engine will use the mini-processor approach, and component 
lookups (which are not that often used) lead to the creation of a 
simple wrapper object implementing the Java interface, but that 
doesn't care about caching as SWT and ZipArchiveSerializer don't care 
about it.


Yes, this sounds like a good compromise. I really think that
the usage of VPC should not be any different than using
"usual" pipeline components - it should be transparent.
I agree that looking up sitemap components outside of the
tree processor does really happen not very often, so
providing such a wrapper is the best way to go.
 

Cool, we found an efficient solution :-)
So, for implementation VPC the only missing piece is resolving
of relative sources, right?
 

Yep. Problem is that currently the "src" attribute is a raw string and 
so we don't absolutize URIs at the place where they're written but at 
the placed where they're used, i.e. potentially in another context.

So we can enforce the contract of "src", stating that it *is* a URI, and 
thus absolutized by the sitemap engine at statement execution time. We 
have to perform extended checks that no component uses it another way 
though. Or we could have a marker interface extending 
SitemapModelComponent that could be used to distinguish the component's 
expectations.

We also need an absolutizer input-module that allows people to 
absolutize URIs used in other attributes than "src". That works pretty 
well using the nested variables resolution we have now, e.g. 


WDYT?
h. let's try to keep it simple and stupid. Today we have
 
that means
 1) type="file" is implicit because it's the default generator for 
these pipelines

 2) "file.xml" is expanded to the local context of the pipeline 
(basically, where the sitemap.xml file is located).

Now, the question you pose is: what if the component needs to access a 
source of a VPC that is not local?

You won't.
It's wrong, IMO, that you have to know something about the resource 
internals of another block, it weakens the contract for no reason 
(because there should be no way for a block to expose its internal 
resources)

So, what if you have a transformer and the stylesheet is located in 
another block?

What you depend on its not the (transformer,stylesheet) couple but the 
(transformation) contract that is performed by these two working together.

So, instead of
 
you do
 
with no source.
What is left to describe is how we define how to go from "blah2html" to 
the actual implementation of that VPC.

Without thinking about intra-block communication, it would be as easy as 
defining a pipeline component as a pipeline fragment in the block 
sitemap (or in your own, if you want).

 
  
 
but how can another block access this?
Each block has a descriptor that identifies:
 1) the URI of the block
 2) the names of the VPC that it exposes
the names of the VPC that it requires can be inferred from the sitemap 
and therefore don't need to be listed explicitly there ( to avoid 
duplication of effort and synch issues).

So, what if the VPC is defined in another block? You do:
 
and the sitemap will transform will know how to get it because, at 
deployment time that "skin" prefix will have been wired to the 
appropriate block URI and therefore the sitemap component manager will 
be able to identify it univocaly.

Now, look at this:
MyBlock depends on Block http://apache.org/cocoon/wiki/1.0 and reference 
it locally as "wiki" and contains the following in one of its pipelines:

 
at deployment time, we have wired that dependency to block 
http://blah.org/myblocks/mywiki that implements 
http://apache.org/cocoon/wiki/1.0 and therefore exposes the following in 
its sitemap

 
  
  
 
 
WDYT?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the 'Real Blocks' issue

Niclas Hedhman wrote:
On Wednesday 20 October 2004 16:23, Antonio Gallardo wrote:

I knew about that. But again the balance would a hard task: Xalan and
Xerces need to move to JAXP 1.3. I already saw the post on the xml-commons
list.

What surprises me about it is that the source of the problem isn't educated 
about the problem of re-using the same interfaces. Why was it so hard for 
them to call it org.w3c.dom3.* ? Sounds to me that those who decide never use 
XML in Java.
very likely to be the case, DOM was created for client side javascript.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ECM++

Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now

[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared that I'll 
get on your nerves when something does not work anymore ...

See my reply to that :) - now 2.2 is in development (alpha) state
so be prepared that things might not work for a longer period of time.

Lenya 1.4 is in alpha state too, so they make a perfect couple :)
OK, I guess at the moment we can't estimate how big the impact
of future changes will be. Actually I'd like to hear Stefanos
opinion on this topic, as he used to care about the cooperation
of the Cocoon and Lenya communities and suggested to do continuous
integration (which is a good thing IMO).
Gump will do continous integration for you, don't worry about that.
Lenya should focus in fixing his own defects first.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: ECM++

Andreas Hartmann wrote:
Carsten Ziegeler wrote:
Yes, it's stable now

[...]
I really hope so :)
We're about to switch to 2.2 for Lenya-dev, so be prepared
that I'll get on your nerves when something does not work
anymore ...
Andreas, I *strongly* suggest that you keep off until we are at least in 
beta state. Or, if you don't, I *even more strongly* suggest you that 
you don't complain if things change under your feet.

Alpha here means "contracts are unstable and rightly so".
You have been warned.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the 'Real Blocks' issue

Ralph Goers wrote:
Antonio,
This subject has come up many times.  I'll restate what I've always said.
If we must release a snapshot jar then the source that was used to build
it must be available for download from Cocoon's website, or another
documented location (i.e. cocoondev, ibiblio, etc.).   I've had too much
trouble in the past trying to track down the source for snapshots.  This
is not an issue for formally released dependencies because almost all of
them release a source package that matches their binary package.
Ehm, sorry, but as long as the CVS repository is public, I see no need 
for this.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ANN] www.nouvo.ch runs on Cocoon!

Giacomo Pati wrote:
On Tue, 28 Sep 2004, Bertrand Delacretaz wrote:
Le 28 sept. 04, à 04:12, Stefano Mazzocchi a écrit :
Bertrand Delacretaz wrote:
...The performance part comes mainly from the front-end apache2 
mod_cache. Simply adding the right HTTP headers and making sure the 
content-length header is generated as well (by setting the buffering 
flag on the HTML serializer) allows the front -end cache to do its 
job very nicely.

uh, I might have missed that part!!! would be cool if you could 
document that.

I'll describe this on the wiki, but basically it's only a case of 
adding the "Last-Modified"; "Expires" and "Cache-Control" headers to 
the response:

final long lastModTime = document.lastModified().getTime();
final long expires = System.currentTimeMillis() + 
(cacheForHowMaySeconds * 1000L);

resp.addDateHeader(LAST_MOD_HEADER,lastModTime);
resp.addDateHeader(EXPIRES_HEADER,expires);
resp.addHeader(CACHE_CONTROL_HEADER,"max-age="+ cacheForHowMaySeconds);
And creating an HtmlSerializer where shouldSetContentLength() returns 
true (we should make this configurable BTW).
Wouldn't mod_header and mod_cache be able to do that for you?
Oh, look! Giacomo is still alive! :-)
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] applying SoC on cocoon itself

Sylvain Wallez wrote:
Stefano Mazzocchi wrote:

and this solves *ALSO* the issue that was identified at the GT about
"virtual pipeline components" resolving services locally or remotely
(block-wise).
The current problem with VPCs is the context in which relative URIs must
be resolved. We have not found a good solution for this as that depends
on the point of view that is considered. What we're missing actually is
the notion of "typed parameter" that would allow us to absolutize a URI
at the closest point where we can determine that it is a URI and not a
raw string.
In the syntax I proposed, the uri="" becomes the identifier for the
service (thru relative to the block that exposes the service) and the
src="" becomes the identifier for the instructions for the service (thus
relative to the block that requires the service).

I think this solves the issue.
it would finally introduce a real "pipeline level" polimorphism that
will allow the creation of real blocks.
Ok, I understand all this and actually this is nothing new compared to
what's already been discussed regarding pipeline services, blocks and
virtual sitemap components. Just that we forgot a bit with all the
classloader shielding and pojo stuff what the actual goal was.
Right, nothing new, but a formalization of why the generator/@src is so
different from transformer/@src.

But still, I don't understand the pattern in "name" in . Does this mean you create a whole space of
transformation services, i.e. blah/a, blah/b, blah/c, etc? IMO, the
service names must be a discrete enumeration, i.e.
http://my/blah/pipeline/service/uri"/>
I thought more about it and I agree, there is no need to introduce token
expansion at the service identification level, so discard that.

Actually, I don't see much difference between pipeline services and
VPCs: pipeline services may simply be the generalization of VPCs looked
up in the current sitemap, ancestor sitemaps or remote blocks ("remote"
meaning in a different block and not on a remote machine).
Correct.
Now, since you are the TreeProcessor guru, how do we implement this? :-D
--
Stefano.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: latest Moin

Upayavira wrote:
I'm probably going to live to regret this, but...
I've just installed the latest Moin wiki for one of my own projects. I 
found a rather more pretty 'right site bar' theme. Just out of 
curiosity, I put the content of the Cocoon wiki into it. You can see it 
at wiki.odoko.co.uk/cocoon

(Note, I won't be leaving that URL active for that long, just offering 
it as an temporary preview).

If you like it, maybe it will enthuse you to help the infrastructure 
group upgrade the Apache wiki farm to use the latest Moin. We could then 
use this theme instead.

Hmm.
+100
I sooo hate the current wiki style.
--
Stefano, who plans to prettyfy that even more if we do...


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

Ugo Cei wrote:
Pier Fumagalli wrote:
The serializers in XALAN are just _VERY_ broken... Why don't we switch 
the default to work on the serializers block? At least it's a 
simple-enough code that we can't fix without too much hassle.
I'm sure you meant "can" instead of "can't" ;-) but anyway, here's my +1.
FYI, as of few days ago, xalan factored out the serializers from their 
main jar file (I know this because they broke 70% of the gump tree in 
doing so ;-)

my +1 on using our own serializers.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] applying SoC on cocoon itself

Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Pier made me realize that there are 3 different issues on the table 
regarding real blocks:

 1) classloading isolation
 2) pojoification
 3) service isolation
and, interestingly enough, they are orthogonal.
Tani was born to prototype 1.
Butterfly was born to prototype 2.
But what I really care is 3!!! and Pier made me realize that you don't 
need to have neither 1 nor 2 to achieve 3!!!

The key is *very* subdle and, in fact, was hard for me to realize before.
Let me show you with an example:
 
 ...
 
This design is 5 years old and does *THIS* really mean? it means that 
the sitemap will lookup a "component" identified by a "class" cast it 
to the functional group (in this case, a transformer), reference it 
with its local name and used with further parameters (the src="").

Now, look at this
 http://apache.org/blah/Blah"/>
   
 

Can you elaborate on this syntax? This reminds me of the pipeline 
services we discussed about 2 years ago [1] (wow, already? Time goes 
fast!), but I don't understand the pattern in the transformer name 
(blah/*).

Sylvain
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103787313407324&w=2
There was always something that bothered me about the differnce between 
a generator/transformer and a serializer. the first two had the src="" 
attribute and the other ones did not.

Moreover, the "fo2pdf" serializers never existed. It was a "Serializer" 
that was identifying the "shape of the java class" and the 
"FopSerializer" that was identifying the implementation of that class, 
but there was never anything that defined the "service" that made 
iTextSerializer and FopSerializer interchangeable.

It made me realize how the use of java classes as identifiers for the 
service behaviors is limited! And it's also the reason why cocoon block 
are not avalon blocks on steroids, but are entirely different things.

So, what's with the above?
There are two types of transformers: compiled and interpreted. for XSLT 
transformations we have both: xalan and xsltc. But what's the similarity 
between the two?

 
is really saying:
 transform the sax stream using the logic contained in the 
news2html.xslt stylesheet.

but then
 
could mean *exactly* the same, where the news2html file was 
"precompiled" into a xsltc translet, and here just identified.

But there is more, the above could well be
 
All represent the *same exact* pipeline service and, in principle, it 
should not be your concern on how this service is implemented, and not 
even *which* block exposes it!

Now, let's get to another thing that always bothered me:
 1) generator src="" -> "what"/"how"
 2) transformer src="" -> "how"
 3) serializer -> none
the use of the src="" attribute makes sense in generators but doesn't 
really make sense in transformers. and in generators, in fact, it's 
nothing more than a parameter that is passed to the generator. Unless, 
ofcourse, the generator is a server page generator, so the src="" 
represent the "what" for the component and the "how" for the pipeline.

What does all this mean?
when you say
 
 
 
you are really stating something like
 http://cocoon.apache.org/services/generation/File"; 
src="blah.xml"/>
 http://cocoon.apache.org/services/transformation/blah2html"/>
 http://cocoon.apache.org/services/serialization/html"/>

and this solves *ALSO* the issue that was identified at the GT about 
"virtual pipeline components" resolving services locally or remotely 
(block-wise).

   - o -
In short: we use the avalon component model for the sitemap machinery 
and that heavily influenced its design. Pojoification is one thing, but 
servification of the pipeline machinery would allow a *far* better reuse 
of pipeline services, implemented both as compiled components, 
interpreted components or virtual components.

*AND*
last but not least,
it would finally introduce a real "pipeline level" polimorphism that 
will allow the creation of real blocks.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] applying SoC on cocoon itself

Ralph Goers wrote:
Is what you said below correct? or did you really intend
http://apache.org/blah/Blah"/>
   

I stand corrected.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: problems starting 2.1.6-dev

Dirk-Willem van Gulik wrote:
On Mon, 18 Oct 2004, Stefano Mazzocchi wrote:

What does this translate to java? Pretty simple, in fact: if you import
a class is fine, if you implement an interface is not.

Let me resend them a msg of a few weeks, months now ago, (to their ED
Bradley Kun and their Compliance Office David Turner).
Dave Turner came out kind of saying the above; but then retracted it again
later in a 'confirmation' of sorts.
Now, whether or not the board digests this is yet another issue and I'm
going to find out soon.
I'll try to give them a call before that.
thanks, Dirk!
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: problems starting 2.1.6-dev

Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Instead of creating yet-another-small-project at cocoondev.org (like 
my own CVSSource), what about creating a general-purpose project that 
would host all interesting cocoon-releated things we cannot host at 
the ASF because of license problems?
What about lobbying about changing the silly LGPL allergy that the ASF 
has instead? Being a director might help at times, you know, that's 
what your (member's) votes were for ;-)
Well, Mr Director, IIRC there's a board meeting tomorrow. 
Wednesday.
Should this subject be added to the agenda?
In fact, I'm going to.
The problem also is that the solution to this problem doesn't depend 
only on the ASF, but also on the FSF which is the mighty priest that 
gives the interpretation of the holy license texts.
Not really. It's neither the FSF nor the ASF that decide if a license 
contract is valid or not, it's a judge, in court. In lack of that, each 
one has its own opinion.

My opinion is that the spirit of the LGPL was that "if you add 
functionality to the library, then you should give it back, if you just 
use the library, your code doesn't have to".

What does this translate to java? Pretty simple, in fact: if you import 
a class is fine, if you implement an interface is not.

I would like to change the ASF policy toward the LGPL saying that 
"importing is ok, implementing is not". That means that if you 
implement, your code has to be LGPL, then you can import that. The 
spirit of the LGPL is maintained and the FSF will not have a problem 
with it, IMO.

Now, whether or not the board digests this is yet another issue and I'm 
going to find out soon.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

[RT] applying SoC on cocoon itself

Pier made me realize that there are 3 different issues on the table 
regarding real blocks:

 1) classloading isolation
 2) pojoification
 3) service isolation
and, interestingly enough, they are orthogonal.
Tani was born to prototype 1.
Butterfly was born to prototype 2.
But what I really care is 3!!! and Pier made me realize that you don't 
need to have neither 1 nor 2 to achieve 3!!!

The key is *very* subdle and, in fact, was hard for me to realize before.
Let me show you with an example:
 
 ...
 
This design is 5 years old and does *THIS* really mean? it means that 
the sitemap will lookup a "component" identified by a "class" cast it to 
the functional group (in this case, a transformer), reference it with 
its local name and used with further parameters (the src="").

Now, look at this
 http://apache.org/blah/Blah"/>
   
 
 ...
 
what does *this* mean?
 1) the sitemap requires a service
 2) the service is located
 3) the service is used
Note that:
 1) no concept of class or interface or role is used.
 2) the two syntaxes are "functionally equivalent", but *ONLY* at a 
local level

  - o -
In short: what I wanted to achieve with real blocks was service isolation.
  Block A requires Service 1 that is described by Block Interface Z and 
exposed by Block B.

Virtual Pipeline components were the first examples of "non java" 
services. (well, ultimately everything ends up being a java class, but 
from a semantic point of view doesn't have to be).

Do we need classloader isolation for the above? NO!!!
So here is my proposal for Cocoon 2.2
 1) fully incremental transition (that's why I welcome Carsten's ECM++ 
solution)

 2) addition of the uri="" attribute to the sitemap component 
descriptors to indicate the "new URI-based lookup behavior", if the 
class="" attribute is used, then it's completely back compatible

 3) implementation of a single-classloader service lookup manager built 
in the sitemap, using the above syntax (the uri="" attribute in the 
component section will trigger the deprecation of the src="" attribute 
in the pipeline section")

 4) implementation of service-based real blocks
The advantages are:
 - fully reversible approach (no back incompatibility, no need to 
rewriting existing code)
 - implementation of polymorphic application level functional units 
(real blocks) as collection of services.
 - started the de-avalonization of the sitemap semantics
 - initiated a smooth migration path toward a service-based 
interpretation of the pipelines that would ease the introduction of 
virtual components

So, what do we lose by not having classloading independence?
 1) hot rewriting (the ability to change an existing service 
implementation at runtime)
 2) class versioning (the ability to have two versions of the same 
exact class running in the same workspace)

I have been blinded by the elegance of 2) for so long that I thought 
that it was somehow a requirement, but the need in real life is yet to 
be demonstrated.

So, as I have indicated, I indent to start working on this transition 
*WITHOUT* interfering with the intra-block or inter-block component 
lookup mechanism, since they are orthogonal.

Comments?
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Building ECM++ for 2.2

Carsten Ziegeler wrote:
The following idea came to my mind during the weekend. All the
recent discussions about a new core/container etc. show that
a possible future version of Cocoon will have a different
component handling than we have now.
One major concern for me is compatibility. It would be bad
if someone had to rewrite his complete application just to
update from one version of Cocoon to another. I guess we
all agree on this. Now reaching this goal can be done
from two sides:
a) The new version can have a compatibility layer.
b) We can provide a smooth transition from version to version.
It would be ideal if we would have both. But with a compatibility 
layer people tend to just use it without migrating their app.

I wondered what we can do to build a better transition and
to get users moving away from our current approach to a 
newer version. A possible way would be to make minor improvements
or modifications from version to version until we reach our
goal. This could e.g. be done by building ECM++ for Cocoon 2.2.

The basic idea is to build an own version of ECM, which is:
grabbing the current ECM code, removing everything we don't
need and build a complete container in Cocoon that provides
the minimum functionality.
This would be:
- using the same configuration (roles and xconf)
- provide support of the following avalon based interfaces:
  LogEnabled, Contextualizable, Parameterizable, Configurable,
  Serviceable, Disposable, Initializable, Startable
What could be the benefit of this? 
- no support for Composable, Component etc. anymore (so no
  proxies and wired wrapping anymore).
- no LogKitManagable, RoleManager support etc.
- no Instrumentation support - we could our own instrumentation (JMX?)
- All the code for this container would be ours - only the marker
  interfaces are of course from Avalon.
- We could easily add new features, like the selector handling
  or the DI from Fortress. Using Fortress is imho out of question
  as it does rely on too many third party code.

By having our own container implementation we could add any support
that we think that makes sense for providing a smooth migration path - 
whereever this path ends :)

Now, doing this is fairly easy; it requires just a bunch of code
and would reduce our depencies while giving us more flexibility.
I just started with this approach and could finish it in the next days
if people think it is worth going this way. It would give 2.2 more meat
as well.
But perhaps this idea is totally foolish?
Thoughts? Comments?
+1000!
the reasons to follow up right after in another RT
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: problems starting 2.1.6-dev

Niclas Hedhman wrote:
On Monday 18 October 2004 15:14, Ugo Cei wrote:

Really? My understanding of this is that the issue is still open:

"As FSF has not yet clarified/answered questions with regard to this,
nor has the LGPL been updated to clarify such - the murkyness around
this makes us do the 'safe' thing; which is to avoid it for the time
beeing."
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing

I haven't checked the 'freshness' of those comments, but
   http://article.gmane.org/gmane.comp.jakarta.poi.devel/5900
seems to give closure, at least until it reaches the courts.
That is ACO's interpretation of somebody's comment from the FSF, neither 
the ASF nor the FSF came to a resolution about it.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: problems starting 2.1.6-dev

Niclas Hedhman wrote:
On Monday 18 October 2004 04:17, Ugo Cei wrote:

No one has ever demonstrated that doing an "import" on classes that are
under the LGPL obliges you to license your code under the (L)GPL. 

The FSF and ASF legal counsel have both said it does.
This is not correct. Some ASF people indicate it's the case, and the FSF 
never said "yes or no" about it.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: problems starting 2.1.6-dev

Sylvain Wallez wrote:
Instead of creating yet-another-small-project at cocoondev.org (like my 
own CVSSource), what about creating a general-purpose project that would 
host all interesting cocoon-releated things we cannot host at the ASF 
because of license problems?
What about lobbying about changing the silly LGPL allergy that the ASF 
has instead? Being a director might help at times, you know, that's what 
your (member's) votes were for ;-)

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

Niclas Hedhman wrote:
On Saturday 16 October 2004 04:55, Stefano Mazzocchi wrote:

Because they have been around forever *AND* they don't change their
contracts overnight. 

Your talk is not entirely reflected by the actions of the community. I just 
did a svn up on the 2.1 branch;

A  lib/endorsed/xalan-2.6.1-dev-20041008T0304.jar
D  lib/endorsed/xalan-2.6.0.jar
Why does the 2.1 branch require a timestamped/snapshot version of Xalan, if 
everything is so fine and dandy with it?
Damn, I am *NOT*. I missed that. We must not depend on timestamped jars 
for such important dependencies.

Antonio?
Antonio makes the following motivation in the commit message;
"Update xalan to 2.6.1-dev-20041008T0304"
Yeah, that's useless. 
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

2004-10-15 Thread Stefano Mazzocchi

Hunsberger, Peter wrote:
Umm, I don't really see a pattern here.  From everything I've seen the
communities involved with Spring and Geronimo have little in common with
the Avalon/Excalibur communities. (Let me qualify that by saying I
haven't looked that closely.) More-over, they both have the advantage of
being able to look at past history and learn from it.  
I need a *record* of stability, the attitude is not enough, I'm sorry.
History should teach people not to repeat the same mistakes 
again... but hey, what do I know, I've only been around here for 7
years.
Many people have learned many things both technically and community wise
in the past 7 years. If it is really this bad why aren't we writing our
own XML parsers and XSLT engines? 
Because they have been around forever *AND* they don't change their 
contracts overnight. Example: xalan2 broke 25% of the gump build last 
night, it was solved after a few hours.

After all they are as critical to
Cocoon as the containers.  Why not take it all the way and write our own
JVM?
FYI, I spent the last day making sure that gump runs against Kaffe and 
GNU classpath to see how far away we are in that regard.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

2004-10-15 Thread Stefano Mazzocchi

Hunsberger, Peter wrote:
> Maybe I'm
just too optimistic in believing there should be container
implementations mature enough for Cocoon to depend on?
What *really* bothers me about this thread is the fact that very few 
seem to realize that "maturity" for dependencies means "stability of the 
contract and stability of the community".

Avalon is dead.
Excalibur is asleep.
Spring is outside the ASF.
Geronimo is still incubating.
Can you see the pattern?
History should teach people not to repeat the same mistakes again... but 
hey, what do I know, I've only been around here for 7 years.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: GT2004 was brilliant

2004-10-15 Thread Stefano Mazzocchi

Ugo Cei wrote:
Il giorno 15/ott/04, alle 12:04, Gianugo Rabellino ha scritto:
Any chance you can "just" iDVD it for now with just separate chapters
per session? I know this would mean a hefty download, but isn't this
why bittorrent is there? Others then might jump in and postproduce the
sessions. But I would certainly like having DVD quality video for the
GT.
I would certainly like this better that last year's videos, whose 
quality was certainly not optimal for, say, projecting them on a large 
screen to your office colleagues (this is not to blame Stefano, who 
probably did the best possible job, given the desired compression levels).

I am just wondering: will we be able to fit everything in a single DVD?
forget it. Last year I had 4 DV tapes for a total of 40Gb. Cut here and 
there and you get 30Gb, reduce quality and framerate by two and you 
might get to 10Gb, but not sure about how presentable it would be.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

Ugo Cei wrote:
Il giorno 14/ott/04, alle 18:09, Vadim Gritsenko ha scritto:
Other question I have is what we are going to do with the component  
base we developed and depend on which currently resides in excalibur  
repository. Should those be copied into Cocoon repository (and  
springified as needed?)?

Things like the SourceResolver, you mean? I have already "springified"  
it and put it (or at least a simplified version of it) here:  
http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/ 
org/apache/butterfly/source/

Actually, I don't like the term "springified". I'd rather say  
POJO-ified, since it has just one dependency upon Spring's  
ApplicationContext (which is needed to resolve paths relative to a  
context's base directory). Maybe there's a way to eliminate even that  
one, but I just did the simplest possible implementation.

This is also meant as a response to Stefano's concerns about depending  
on an alien framework. Once again, I am trying to show that, once you  
have swallowed the Dependency-Injection kool-aid, your components have  
very limited dependencies on the framework, or even none at all. So we  
can design generators, transformers, serializers, etc. that can be  
deployed _today_ in any existing DI container, and tomorrow in our own  
container that is designed specifically and optimized for our needs,  
without rewriting a single line of code! If you take a look at the  
sitemap components that are now in Butterfly, you will find exactly  
ZERO dependencies on Spring. And they work, even if in a simplified  
scenario, but you can get a fscking HTML response from the Butterfly  
servlet using a generator-transformer-serializer pipeline NOW.  
Admittedly, it's more of a proof of concept than a usable thing  
(there's no caching, no sitemap processor, etc.) but it shows it can be  
done.

I could have started by doing my own container (after all, it's not  
rocket science, right?) and today I would be nowhere near where I am,  
given the copious free time I have available. Or I could have used the  
best DI container around and got some real work done. What would have  
you done in my place?
All right, do-ocracy wins.
Now, let's make it happen.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

Ugo Cei wrote:
Il giorno 14/ott/04, alle 16:50, Stefano Mazzocchi ha scritto:
real block kernel and Rickard Oberg's AOP framework, this would be 
modern.
Too bad he has not open-sourced it yet, or has he?
No, and he will not.
But the ideas are available and implementation doesn't scare me.
My point remains: we've been burned too much before already in depending 
on frameworks we don't control.

I still think it would be better to write our own entirely from scratch.
Want to use ideas for Spring? sure, bring them on, but depending on it 
is asking for trouble.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

Sylvain Wallez wrote:
Vadim Gritsenko wrote:

Personally, I'd favor Avalon support for chosen container. As Ralph 
noted, and he is not alone, people like Avalon, and we should support 
it for years to come.
Well, people will like DI containers once they start using them :-)
DI is 1% of the original avalon idea. In fact, the only thing that was 
injected were the configurations and the component manager (than people 
saw that and not the real power of simple aspect orientation and Fowler 
made it big misnaming it).

Technologically speaking, I still believe that the original 
block+component avalon model is far superior to a silly DI pattern.

real block kernel and Rickard Oberg's AOP framework, this would be modern.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Cocoon undergo phase transition when moving from 1.x to 2.x.
Are we doing it again?
The question on the table is: we *NEED* better class discovery and 
classloading isolation. This is a must, just like the need for SAX 
pipelines drove 2.x away from 1.x in a non-incremental way (phase 
transition, as I said).

Can we implement classloading isolation with incrementally modifying 
what we already have?

 From the descriptions sent by Ugo and Sylvain, they both agree that 
"kernel container" is something completely different than "intra-block 
container", which means that it should be implemented on top of existing 
Cocoon codebase as loader and manager of intra-containers regardless of 
particular technology used for implement intra-container (ECM, Spring, 
shell script...)

So me feeling here is that these are two separate threads;
 * Steps to implement "kernel container".
   Pier made the first step already.
 * Directions for improvement "intra container".
   One decision we made recently was (finish) the move to Fortress.
We can back up from that commitment and choose different target, be it 
Nano/Pico/Merlin/etc, but it should be independent of kernel container, 
so we can do that in parallel tracks.

And one more discussion thread is needed, about roadmap for 2.1 branch, 
2.2 branch, and possibly 2.3. Cocoon 2.2 is a good place to introduce 
fortress, and Cocoon 2.3 can have other intra-container implementations, 
whatever we choose.
Vadim, let me be crystal clear: I DO NOT want to depend on fortress!
I've been trying to get that fucking thing working and it depends on 
things that Berin has on d-haven.org and only *HE* maintains.

We didn't want Merlin because it was a one man show, but Fortress is way 
more of a one man show that Merlin is (at least Merlin compiles in gump, 
)

I have great respect for the people involved, but they are not a 
community, they are a bunch of avalon refugees and that's the only thing 
that unifies them.

Depending more on avalon/merlin/excalibur will just hurt us more.
--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [RT] Some notes about the "Real Blocks" issue

Niclas Hedhman wrote:
Being a die-hard Avalon supporter, I am all in favour of progress, but for the 
right reasons. Swapping ECM/Fortress for Spring/Pico doesn't change anything 
fundamentally. Only creates a lot of work for no immediate benefit.
The real challenge as someone pointed out, is the classloading management to 
support "real blocks". THAT is worth an effort, all IMHO of course.
Niclas,
let me suggest you to consider something that nobody else will 
explicitly say but "we are sick of avalon".

It doesn't matter how good it is, fortress, merlin, metro, you name it. 
It hurts. It's fragile.

Look at ant, xerces, xalan! Those are things you can count on. You 
*know* how painful it is to make excalibur running, how fragmented and 
careless the entire avalon community is.

Avalon = pain
ask around: james, the incubated directory project, even fulcrum. Ask 
them about avalon and they reply "if I knew then what I know now! :-(" 
[had this conversation, again, no longer than yesterday!]

Nicola, former PMC chair of avalon wrong "avalon must die!"
What else do you want? it's not a matter of cleaning up ECM, we want 
avalon to be considered legacy, we want to move away from it.

I don't know if Spring will be better, that's why I much rather would 
want to invent our own that to depend on somebody elses (writing a 
dep-inj container is piece of cake, c'mon)

it's not technology, it's psychology.
we have reached one of those "phase transitions" since avalon's 
interfaces for component lookup don't support the needs for real blocks.

mix the "sick and tired of avalon"-ness and you get an increase of 
entropy and an irreversible state transition but this community is 
strong, healthy, diverse and yet united on the move (even more so after 
the GT) so I see no problems, not for the project nor for the users.

--
Stefano.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Daisy as CMS: why don't use JDO?