Since we have put our bets on javascript, it may be inetresting to
follow discussions about the new Javascript.
http://www.mozilla.org/js/language/js20/
The nice thing is that the discussions seem to point to a more
Java/Python-esque language, that can only make us happy :-)
--
Nicola Ken Baro
On Sat, Jun 21, 2003 at 06:12:15PM -0400, Vadim Gritsenko wrote:
Geoff Howard wrote:
Can we do something more drastic to the xml-cocoon2 repository that would
prevent people from making this innocent mistake? What about removing
everything except a README.TXT or something?
I hope you really mean:
On Sat, Jun 21, 2003 at 06:12:15PM -0400, Vadim Gritsenko wrote:
> Geoff Howard wrote:
...
> >Can we do something more drastic to the xml-cocoon2 repository that would
> >prevent people from making this innocent mistake? What about removing
> >everything except a README.TXT or something?
> >
>
>
> -Original Message-
> From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
> Geoff Howard wrote:
>
> >This guy along with a bunch of others found old instructions about
> >xml-cocoon2
> >
>
> xml-cocoon2 is a symlink right now:
>
> lrwxrwxr-x 1 pier cvsadmin 19 Feb 26 18:23 xml-cocoon2@ ->
>
Geoff Howard wrote:
This guy along with a bunch of others found old instructions about
xml-cocoon2
xml-cocoon2 is a symlink right now:
lrwxrwxr-x 1 pier cvsadmin 19 Feb 26 18:23 xml-cocoon2@ ->
cocoon-2-historical
and did a cvs checkout of HEAD thinking he was getting 2.1m3-dev.
Can we do
This guy along with a bunch of others found old instructions about
xml-cocoon2
and did a cvs checkout of HEAD thinking he was getting 2.1m3-dev.
Can we do something more drastic to the xml-cocoon2 repository that would
prevent people from making this innocent mistake? What about removing
everythi
will probably be more efficient, but as there hasn't
been many answers to your proposal, you probably need to seed the
project with some code first to get feedback. If you can send a patch it
could be a start (assuming others are ok on having such a sample as a
block in Cocoon).
I agree, a see
ussions on this list, or should I
start a
project elsewhere (e.g. SF/Krysalis/CocoonDev) and report back to this
list on significant events?...
Discussing it here will probably be more efficient, but as there hasn't
been many answers to your proposal, you probably need to seed the
project wit
I have recently been discussing with Carsten the need for a use case
that illustrates many of the features in the new portal framework. With
this in mind I will soon be starting a project to develop just such a
use case. The purpose of this mail is twofold:
1) notify the community of this project
2
Stefano Mazzocchi wrote:
> > I mean, when something is in there for ages and noone maintains it
> > or uses it, it is pretty useless. What do you think?
>
> yes and no. i would think that leaving stuff on the scratchpad doesn't
> really hurt anybody. I would suggest, instead, to keep it as a
> scr
on 5/28/03 8:03 AM Christopher Oliver wrote:
> FlowVelocityGenerator to replace VelocityGenerator
Does it have any drawbacks? if not, +1 all the way.
--
Stefano.
on 5/28/03 7:29 AM Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>Here is what I propose to move:
>>
>> 1) ImageReader
>> 2) Paginator
>> 3) JXTemplate*
>>
>
> +1
>
>
>>anything else?
>
>
> Do we have any policy when to blast things from the scratchpad,
no, we don't.
> I mean, when
At 02:15 AM 5/28/2003, you wrote:
Here is what I propose to move:
1) ImageReader
+1 Couldn't figure out why it was in scratchpad.
Don't know much about the others.
Geoff
Christopher Oliver wrote:
Vadim Gritsenko wrote:
...
First we are creating blocks for more modular design and the next
thing is we are coupling everything back into monolith. I feel that's
not the right way to go.
We've got more than 5Mb worth of optional JARs (not counting blocks'
libs) and
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Vadim Gritsenko wrote:
Christopher Oliver wrote:
FlowVelocityGenerator to replace VelocityGenerator
-1 to replacing: FlowVelocityGenerator introduces dependencies on
org.apache.commons.jxpath and org.mozilla.javascript
Sorry, org.mozilla.
Christopher Oliver wrote:
Vadim Gritsenko wrote:
Christopher Oliver wrote:
FlowVelocityGenerator to replace VelocityGenerator
-1 to replacing: FlowVelocityGenerator introduces dependencies on
org.apache.commons.jxpath and org.mozilla.javascript
Sorry, org.mozilla.javascript is not a probl
Vadim Gritsenko wrote:
Christopher Oliver wrote:
FlowVelocityGenerator to replace VelocityGenerator
-1 to replacing: FlowVelocityGenerator introduces dependencies on
org.apache.commons.jxpath and org.mozilla.javascript which where
missing in original VelocityGenerator.
Why is that a problem?
Christopher Oliver wrote:
FlowVelocityGenerator to replace VelocityGenerator
-1 to replacing: FlowVelocityGenerator introduces dependencies on
org.apache.commons.jxpath and org.mozilla.javascript which where missing
in original VelocityGenerator.
Also, does it support functionality which is
FlowVelocityGenerator to replace VelocityGenerator
Stefano Mazzocchi wrote:
Here is what I propose to move:
1) ImageReader
2) Paginator
3) JXTemplate*
anything else?
Stefano Mazzocchi wrote:
> Here is what I propose to move:
>
> 1) ImageReader
> 2) Paginator
> 3) JXTemplate*
>
+1
> anything else?
Do we have any policy when to blast things from the scratchpad,
I mean, when something is in there for ages and noone maintains it
or uses it, it is pretty usel
Here is what I propose to move:
1) ImageReader
2) Paginator
3) JXTemplate*
anything else?
--
Stefano.
Stefano Mazzocchi dijo:
> on 4/12/03 5:03 PM Geoff Howard wrote:
>
>
>> I'd be for it - but what about bugs marked blocking 2.1 release? And
>> what about pending major changes to central contracts (flow)?
>> How do we avoid getting stalled in beta?
>
> by releasing early and often, fixing one iss
Stefano Mazzocchi dijo:
> a) they get a release we consider stable in code (in fact cocoon
> 2.1-dev is pretty damn rock solid from a code point of view, I never had
> a failure in months and many are using it in production with no
> problems)
>
> What do you think?
I think there are just one imp
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
...
So I'm thinking about a global logger dedicated to deprecation
messages. This would allow to write all messages going to that
logger to e.g. a "deprecated.log" file.
...
Nice suggestion; but can't we just use WARN for de
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Hi folks,
We have in the 2.1 a number of features that are considered as
deprecated, although still supported. We need a way to inform users
(the ones that write Cocoon apps) that they use such deprecated
features in a way that allows them to be fo
Sylvain Wallez wrote:
Hi folks,
We have in the 2.1 a number of features that are considered as
deprecated, although still supported. We need a way to inform users
(the ones that write Cocoon apps) that they use such deprecated
features in a way that allows them to be found easily, and not
int
Hi folks,
We have in the 2.1 a number of features that are considered as
deprecated, although still supported. We need a way to inform users (the
ones that write Cocoon apps) that they use such deprecated features in a
way that allows them to be found easily, and not intermixed in the usual
lo
On Monday 24 March 2003 19:13, Stefano Mazzocchi wrote:
> This is not a run for market share.
Isn't it??? The day the flow of developers goes towards .NET, the Java
advantage will disappear as well, the community will dry up of fresh blood.
The attitude "We don't want new people use our product
Le Mardi, 25 mars 2003, à 20:36 Europe/Zurich, Nicola Ken Barozzi a
écrit :
Again I repeat my suggestion... what about driving users to
Forrest for the impatient? It also contains preconfigured stuff for
site building, it seems perfect for the impatient, no?
I also missed it the first time
Stefano Mazzocchi wrote:
Am I the only one who heard complains about cocoon being very cool but
too hard to 'tune down' to simpler needs?
I'm asking because I'm starting to wonder if this is the case.
It's still 116 mails to go... But no, you are not alone.
Vadim
On Sunday 23 March 2003 15:25, Stefano Mazzocchi wrote:
[snip]
> I propose to ship Cocoon 2.1 *AS IS*, sort of a cleaned-up version of
> our current CVS and improve a little the 'INSTALL.txt' doc that will
> suggest you to do
>
> $> ./build.sh
> $> ./cocoon.sh servlet
>
Isn't it possible to
> Again I repeat my suggestion... what about driving users to Forrest for
> the impatient? It also contains preconfigured stuff for site building,
> it seems perfect for the impatient, no?
>
> --
> Nicola Ken Barozzi [EMAIL PROTECTED]
Sorry I missed it the first time around.
Yes
Stephan Michels wrote, On 25/03/2003 18.46:
On Tue, 25 Mar 2003, J.D. Daniels wrote:
...
See where I am going here? This is what (IMHO) most of new cocoon users are
like. We are experienced developers. but chances are we won't be java
aware so the idea of two extra binaries will, i think sl
> No no, it's very useful. Maybe I'm wrong :-/ I only want to prevent
> that users be scared by the installation, which takes sometimes a lot of
> time and knowledge. I'm, for example, very impatient, if some software
> takes too much time, or too many dependencies just for the first look,
> then
Hi, sorry to butt in like this, but I am a newcomer to Cocoon, and I
must say I am a bit worried by this suggestion. Trying to build Cocoon
2.1 dev on my W2K work station has proved a bit of a head ache. I have
checked the newest version from CVS to C:\Src\new_cocoon-2.1 on my
machine. When I t
J.D. Daniels wrote:
Cocoon is not an app.
It is a framework.
Amen!
And our users are not idiots, but experienced web programmers.
Let's treat them as such.
Stefano.
On Tue, 25 Mar 2003, J.D. Daniels wrote:
>
> > > So I whould like a solution there we offer a source distribution, and
> > > binary distribution with a war, which includes all samples, and one
> clean
> > > war. So the user can first download the bin-dist, test all samples,
> > > and experimental
At 12:11 PM 3/25/2003, you wrote:
> > So I whould like a solution there we offer a source distribution, and
> > binary distribution with a war, which includes all samples, and one
clean
> > war. So the user can first download the bin-dist, test all samples,
> > and experimentalize with the clean w
> > So I whould like a solution there we offer a source distribution, and
> > binary distribution with a war, which includes all samples, and one
clean
> > war. So the user can first download the bin-dist, test all samples,
> > and experimentalize with the clean webapp. And then he is glad and wan
Stephan Michels wrote:
On Sun, 23 Mar 2003, Stefano Mazzocchi wrote:
In the beginning, there was only one cocoon distribution, packaged with
two different packagers (zip for windows and tar.gz for unix and friends).
Then cocoon became very complex and we decided to create a binary
distribution to
On Sun, 23 Mar 2003, Stefano Mazzocchi wrote:
> In the beginning, there was only one cocoon distribution, packaged with
> two different packagers (zip for windows and tar.gz for unix and friends).
>
> Then cocoon became very complex and we decided to create a binary
> distribution to make things
On wto, mar 25, 2003 at 10:17:40 +0100, Stefano Mazzocchi wrote:
> Leszek Gawron wrote:
> >I think it would be good to include AJP13 Listener in Jety config file so
> >one
> >could use Apache frontend OOTB
>
> read this:
>
> http://wiki.cocoondev.org/Wiki.jsp?page=ApacheModProxy
I have complete
Geoff Howard wrote:
On a side note, I looked at Cocoon a full year (or so) before I started
using it and just passed it by because I couldn't quickly see if it
could do what I wanted, and assumed it didn't. Just trying to learn
from that now that I'm on the other side of the fence.
This is tal
Leszek Gawron wrote:
I think it would be good to include AJP13 Listener in Jety config file so one
could use Apache frontend OOTB
read this:
http://wiki.cocoondev.org/Wiki.jsp?page=ApacheModProxy
Great! I wanted to propose exactly the same next week,
you must read my mind sometimes :)
So, a big +1 for only a source dist.
Carsten
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 23, 2003 3:25 PM
> To: Apache Cocoon
> Sub
Pier Fumagalli wrote, On 24/03/2003 20.34:
On 24/3/03 11:00 am, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
Stefano Mazzocchi wrote, On 24/03/2003 11.53:
...
1) bandwidth reduction
Then start taking ant away from CVS and distros, and use a mirrored
download for the jars, it's part of the sa
At 03:50 PM 3/24/2003, Pier wrote:
On 24/3/03 8:44 pm, "Geoff Howard" <[EMAIL PROTECTED]> wrote:
> At 03:38 PM 3/24/2003, you wrote:
>> On 24/3/03 7:42 pm, "Leszek Gawron" <[EMAIL PROTECTED]> wrote:
>>
>>> I think it would be good to include AJP13 Listener in Jety config file
>> so one
>>> could u
On 24/3/03 8:44 pm, "Geoff Howard" <[EMAIL PROTECTED]> wrote:
> At 03:38 PM 3/24/2003, you wrote:
>> On 24/3/03 7:42 pm, "Leszek Gawron" <[EMAIL PROTECTED]> wrote:
>>
>>> I think it would be good to include AJP13 Listener in Jety config file
>> so one
>>> could use Apache frontend OOTB
>>
>> I a
At 03:38 PM 3/24/2003, you wrote:
On 24/3/03 7:42 pm, "Leszek Gawron" <[EMAIL PROTECTED]> wrote:
> I think it would be good to include AJP13 Listener in Jety config file
so one
> could use Apache frontend OOTB
I am _strongly_ against this: the inclusion of Jetty in the Cocoon
distribution is an
On 24/3/03 7:42 pm, "Leszek Gawron" <[EMAIL PROTECTED]> wrote:
> I think it would be good to include AJP13 Listener in Jety config file so one
> could use Apache frontend OOTB
I am _strongly_ against this: the inclusion of Jetty in the Cocoon
distribution is an "enabler" for technology-showoff (y
I think it would be good to include AJP13 Listener in Jety config file so one
could use Apache frontend OOTB
ouzo
--
__
| / \ |Leszek Gawron// \\
\_\\ //_/ [EMAIL PROTECTED] _\\()//_
.'/()\'. Phone: +48(600)3411
On 24/3/03 11:00 am, "Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
> Stefano Mazzocchi wrote, On 24/03/2003 11.53:
> ...
>> 1) bandwidth reduction (yes, this should be our concern as cocoon is
>> getting so big)
>
> Then start taking ant away from CVS and distros, and use a mirrored
> download
IMHO:
Cocoon is best suited to people who develop using other technologies - PHP
C++ Visual Basic etc, who have realized the limitations for end user
interaction.
Within a half hour, right now the way the system is, you can see what cocoon
does. It isn't an app, it is not a solution. It is a tool
At 10:41 AM 3/24/2003, Stefano wrote:
Steven Noels wrote:
On 24/03/2003 15:28 Stefano Mazzocchi wrote:
I for one think the 'copy cocoon.war into webapps dir and look at
http://server:port/cocoon/' paradigm helps a lot of newcoming users up
& running very fast.
please, define 'be up and running
Steven Noels wrote:
On 24/03/2003 15:28 Stefano Mazzocchi wrote:
I for one think the 'copy cocoon.war into webapps dir and look at
http://server:port/cocoon/' paradigm helps a lot of newcoming users
up & running very fast.
please, define 'be up and running'.
Not knowing about javac, ant, an
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
Yes. This is going to be even more with the introduction of the flow
since people with client-side knowledge (html + css + javascript + xml
+ namespace + xslt) will be able to write full-blown web applications
with database connectivity *without* a
At 09:28 AM 3/24/2003, Stefano wrote
Am I the only one who heard complains about cocoon being very cool but too
hard to 'tune down' to simpler needs?
I'm asking because I'm starting to wonder if this is the case.
Stefano.
No, you're not crazy. This has been a theme for a while. In fact, i
At 05:14 AM 3/24/2003, Stefano wrote:
Hmmm, I was thinking about adding build profiles the other day.. something
like:
./build.sh --profile=[profile] webapp
that will override the build properties from
[profile].properties
that include several different configuration properties that drive
> life easier. So let's get over with this, and see what the users think.
> They've been kept out of the loop for too long.
>
How about _asking_ the users beforehand? A quick poll in the users list
would give some helpful feedback wouldn't it?
Matthew
On 24/03/2003 15:28 Stefano Mazzocchi wrote:
I for one think the 'copy cocoon.war into webapps dir and look at
http://server:port/cocoon/' paradigm helps a lot of newcoming users up
& running very fast.
please, define 'be up and running'.
Not knowing about javac, ant, and whatelse, just doing
Le Lundi, 24 mars 2003, à 15:31 Europe/Zurich, Geoff Howard a écrit :
...Would it help the psychological barrier to have a user friendly
"Where is the binary" document/paragraph available and hard to miss
that explains why we think even non programmers can and should build
this from source?
Not
Stefano Mazzocchi wrote, On 24/03/2003 15.23:
...
Nicola, in a perfect world, we would have totally isolated dynamic
blocks with a super block manager and totally run-time hot-deployable
stuff.
In that case, we would *NOT* need a source distro at all because people
would be able to tune their
Stefano Mazzocchi wrote:
Geoff Howard wrote:
At 06:13 AM 3/24/2003, you wrote:
Niclas Hedhman wrote:
On Monday 24 March 2003 17:25, Christian Haul wrote:
This is an open *source* project, and a couple of things are a lot
easier to do at compile time rather than at run time.
Yes, like
./confi
At 09:03 AM 3/24/2003, Stefano wrote:
Geoff Howard wrote:
Cocoon cuts across a number of different disciplines (java, xml at
least?) and so "casual programmer" means different things.
Very true.
I am amazed at the number of people on users who claim to know no java.
Yes. This is going to be eve
Steven Noels wrote:
On 24/03/2003 14:01 Upayavira wrote:
Great! Do others think this is worth doing?
Possible, sure. Worth doing, I really don't know.
I won't vote against it but I won't help it making it happen.
Related to this thread:
I for one think the 'copy cocoon.war into webapps dir and
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 24/03/2003 12.21:
Nicola Ken Barozzi wrote:
...
I'm sure that if we don't give our users a sample precompiled version
it will have a really negative impact on the alpha-view of Cocoon and
stop many from checking it out, whatever technical
Le Lundi, 24 mars 2003, à 14:45 Europe/Zurich, Stefano Mazzocchi a
écrit :
...Right. I'll commit a dist target today to show you what I mean and
we'll vote from that, ok?
Way to go - this will help us make a better decision, and it doesn't
prevent making binary dists later on if needed.
...do
Geoff Howard wrote:
At 06:13 AM 3/24/2003, you wrote:
Niclas Hedhman wrote:
On Monday 24 March 2003 17:25, Christian Haul wrote:
This is an open *source* project, and a couple of things are a lot
easier to do at compile time rather than at run time.
Yes, like
./configure --prefix=/usr/local/
m
Bertrand Delacretaz wrote:
Le Lundi, 24 mars 2003, à 12:38 Europe/Zurich, Upayavira a écrit :
But we have to take psychology into account. CVS scared me at
first. Build scared me
too. How do we make the learning curve easier? Why loose people who
don't get
past those first hurdles, when they
On Monday, March 24, 2003, at 07:50 AM, Bertrand Delacretaz wrote:
A source-only distribution is not necessarily harder to use, it all
depends how it is packaged and used.
... and documented. Most of the problems I've had with oss
make-install-before-try software were related to some glitch,
e
On 24/03/2003 14:01 Upayavira wrote:
Great! Do others think this is worth doing?
Possible, sure. Worth doing, I really don't know.
Related to this thread:
I for one think the 'copy cocoon.war into webapps dir and look at
http://server:port/cocoon/' paradigm helps a lot of newcoming users up &
Stefano Mazzocchi wrote, On 24/03/2003 12.21:
Nicola Ken Barozzi wrote:
...
I'm sure that if we don't give our users a sample precompiled version
it will have a really negative impact on the alpha-view of Cocoon and
stop many from checking it out, whatever technical motive you may have.
I *stro
At 06:13 AM 3/24/2003, you wrote:
Niclas Hedhman wrote:
On Monday 24 March 2003 17:25, Christian Haul wrote:
This is an open *source* project, and a couple of things are a lot
easier to do at compile time rather than at run time.
Yes, like
./configure --prefix=/usr/local/
make
make install
for spe
On 24 Mar 2003 at 13:50, Bertrand Delacretaz wrote:
> A possible scenario would be:
> -user installs Java Web Start
> -user goes to the Cocoon download page, clicks on a JNLP link which
> starts a small install GUI -install GUI helps user download the Cocoon
> source (maybe even specific CVS tags)
Le Lundi, 24 mars 2003, à 12:38 Europe/Zurich, Upayavira a écrit :
But we have to take psychology into account. CVS scared me at
first. Build scared me
too. How do we make the learning curve easier? Why loose people who
don't get
past those first hurdles, when they may well be perfectly capab
On Monday 24 March 2003 18:14, Stefano Mazzocchi wrote:
> Niclas Hedhman wrote:
> > BUT, a cocoon-sample.war would be great for "Introduction". I.e. Download
> > that, drop it in your servlet container, and you have Cocoon's samples
> > running. I'm sure "build process" scares away some users insti
Stefano wrote:
> > It's not a technical point, if it were only so we would be doing
> > releases by just tagging CVS probably.
>
> I don't like your tone.
I'm afraid on this point I agree with Nicola Ken. From a technical perspective, it
makes complete sense to use a source build (even point peo
> I'm not saying to make it inherently difficult for people (rather the
> opposite, look how much energy I'm investing into this!) but to help
> them focus on the right spot and if this makes more people fail early
> rather than a few tens of emails down the road, well, I'm doing both
> them and ou
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 24/03/2003 11.53:
...
1) bandwidth reduction (yes, this should be our concern as cocoon is
getting so big)
Then start taking ant away from CVS and distros,
This is coming up next! :)
and use a mirrored
download for the jars, it's part of t
Niclas Hedhman wrote:
On Monday 24 March 2003 17:25, Christian Haul wrote:
This is an open *source* project, and a couple of things are a lot
easier to do at compile time rather than at run time.
Yes, like
./configure --prefix=/usr/local/
make
make install
for specifying installation directory
Le Lundi, 24 mars 2003, à 11:43 Europe/Zurich, Stefano Mazzocchi a
écrit :
...Oh, sure, but I was thinking of calling the distribution
Apache_Cocoon_2.1.zip (or something like that)
so it won't have "source" written anywhere.
ok - if the distribution is "psychologically correct" then I'm fine.
W
Stefano Mazzocchi wrote, On 24/03/2003 11.53:
...
1) bandwidth reduction (yes, this should be our concern as cocoon is
getting so big)
Then start taking ant away from CVS and distros, and use a mirrored
download for the jars, it's part of the same thing.
I'm sure that if we don't give our users
Sylvain Wallez wrote:
Cocoon is now a major opensource product, and as such its user base
includes more and more people that are far less technically skilled than
we are. Moreover (I already mentioned this) the power of Cocoon's
builtin components leads to many people using it without ever open
Bertrand Delacretaz wrote:
Le Dimanche, 23 mars 2003, à 15:25 Europe/Zurich, Stefano Mazzocchi a
écrit :
...
Before you jump up and down and scream "no, no, binaries are easier
for our users", get off your
life-without-a-compiler-windows-inflicted-mindset and think that every
JDK comes with a
On 24.Mar.2003 -- 05:36 PM, Niclas Hedhman wrote:
> On Monday 24 March 2003 17:25, Christian Haul wrote:
> > This is an open *source* project, and a couple of things are a lot
> > easier to do at compile time rather than at run time.
>
> Yes, like
>
> ./configure --prefix=/usr/local/
> make
> ma
Niclas Hedhman wrote:
On Monday 24 March 2003 02:08, Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote, On 23/03/2003 15.25:
What do you think?
+1 for the source distro.
I agree, except...
As for the binary distro, we simply never did one really. What I'd like
to see is
cocoon-full.war
no
J.D. Daniels wrote:
Well I am just a user... But you hit the nail right on the head there. I had
cocoon up and running within minutes the first time I found it, but was
extremely frustrated for months afterward, because I could load the samples
page... and SEE what it could do, but not be able to i
On Monday 24 March 2003 17:25, Christian Haul wrote:
> This is an open *source* project, and a couple of things are a lot
> easier to do at compile time rather than at run time.
Yes, like
./configure --prefix=/usr/local/
make
make install
for specifying installation directory, right?
Need to t
On 23.Mar.2003 -- 03:25 PM, Stefano Mazzocchi wrote:
> I propose to ship Cocoon 2.1 *AS IS*, sort of a cleaned-up version of
> our current CVS and improve a little the 'INSTALL.txt' doc that will
> suggest you to do
>
> $> ./build.sh
> $> ./cocoon.sh servlet
>
> and voila', that was it! or, i
Stefano Mazzocchi wrote:
In the beginning, there was only one cocoon distribution, packaged
with two different packagers (zip for windows and tar.gz for unix and
friends).
Then cocoon became very complex and we decided to create a binary
distribution to make things easier. Things were indeed e
Le Dimanche, 23 mars 2003, à 15:25 Europe/Zurich, Stefano Mazzocchi a
écrit :
...
Before you jump up and down and scream "no, no, binaries are easier
for our users", get off your
life-without-a-compiler-windows-inflicted-mindset and think that every
JDK comes with a compiler.
Technically, I'm w
On Monday 24 March 2003 02:08, Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote, On 23/03/2003 15.25:
> > What do you think?
>
> +1 for the source distro.
I agree, except...
> As for the binary distro, we simply never did one really. What I'd like
> to see is
>
>cocoon-full.war
no need, I
little better.
JD
- Original Message -
From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
To: "Apache Cocoon" <[EMAIL PROTECTED]>
Sent: Sunday, March 23, 2003 6:25 AM
Subject: [proposal] a new kind of 'dist'
> In the beginning, there was only
Stefano Mazzocchi wrote, On 23/03/2003 15.25:
...
So, in light of the good old triad
./configure; make; make install
I propose to ship Cocoon 2.1 *AS IS*, sort of a cleaned-up version of
our current CVS and improve a little the 'INSTALL.txt' doc that will
suggest you to do
$> ./build.sh
$>
In the beginning, there was only one cocoon distribution, packaged with
two different packagers (zip for windows and tar.gz for unix and friends).
Then cocoon became very complex and we decided to create a binary
distribution to make things easier. Things were indeed easier for new
users to ins
Stefano Mazzocchi wrote:
The problem with having an environment-dependent serializer is that the
cache needs access to it because it might change its behavior depending
on environment parameters.
IIRC, the reason why serializers are "special" WRT cache stuff is
exactly this (i.e. circular reas
(cc to -docs for info, please discuss on -dev)
Recent activity on the cocoon-docs list suggests that the
Forrestization of our docs might be happening soon, and this raises
some issues due to the circular dependencies that this creates between
Cocoon and Forrest.
See [1] and [2].
Could we add
Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
If you start adding the environment, this is not true anymore and we
must cache *BOTH* the pipeline output (as xml) and the serializer
output (as binary) because their ergodicity can be different.
This is the only concern I'm having.
If enough
Stefano Mazzocchi wrote:
If you start adding the environment, this is not true anymore and we
must cache *BOTH* the pipeline output (as xml) and the serializer output
(as binary) because their ergodicity can be different.
This is the only concern I'm having.
If enough people believe this is a
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
One word: CacheableProcessingComponent. IIRC, cache was aware of
cacheable serializers some time ago. The only missing piece is to add
SitemapModelComponent support for Serializers.
Yes, the caching algorithm queries serializers if they support cac
1 - 100 of 1087 matches
Mail list logo
