You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Vadim Gritsenko <va...@verizon.net> on 2001/11/01 05:33:55 UTC

RE: [C2]: Release Candidate 2

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Wednesday, October 31, 2001 6:23 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [C2]: Release Candidate 2
> 
> Sylvain Wallez wrote:
> >
> > Carsten Ziegeler a écrit :
> > >
> > > Hi Team,
> > >
> > > some days ago we decided to make the release candidate 2
> > > on next monday (5th of november).
> > >
> > > The question is now, what has to be done until then?
> > >
> > > 1) We have many open bugs in bugzilla. These must be reviewed
> > >    and then solved (or declared invalid etc).
> >
> > Going to nagoya to pick up some ;)
> >
> > > 2) Documentation updates (this area lacks most)
> > >    We could move this to the final release.
> >
> > Documentation is a must have to gain a lot of users, but it's a
> > non-final release that stops big companies from using Cocoon. So
let's
> > not delay the release because of docs.
> 
> Very good point. +1
> 
> Documentation is a must, I agree, but software stability is what many
> are looking for to even start looking at it. We will make docs better,
> but let's follow the release early and often practice a little bit
more
> ok? (it's *TWO* years we are working on Cocoon2, damn it!)
> 
> > > 3) Decide what to backport from the 2.1 head.
> > >    I'm +1 on removing the CodeFactories completly in 2.0, too.
> > >    This would avoid any backcompatibility problems.
> >
> > +1 also, along with the changes on Cocoon/Sitemap that turns it into
a
> > real component.
> 
> +1 as long as it doesn't change current behavior.
> 
> > > 4) Layout the distribution
> > >    This is a point we haven't discussed yet. Currently our
> > >    distribution is a mixture of a source and a binary one.
> > >    We deliver the source and a compiled version, but in order
> > >    to run Cocoon, the user has to build a war file.
> > >    I propose to split this: one source distribution which is
> > >    similar to the current one but without the precompiled
> > >    cocoon jar and a binary distribution containing only the
> > >    war file. This war file should work in most servlet engines,
> > >    perhaps not in all.
> 
> +1 for both solutions.
> 
> 1) the "ready to be deployed - almost-demo-app" (which, IMO, should
also
> contain the cocoon docs in the webapp since they are served by Cocoon
> anyway) packaged as a big WAR file.
> 
> 2) the normal distribution.
> 
> What do you think?

+1 for both. Also, people on user list expressed interest in having
option to download Cocoon bundled with servlet engine, say, Tomcat 4, so
you need only to download it and launch it out of the box. I do
understand that Cocoon is extremely simple to install (especially on
TC4), but we had lots of emails from users being unable to do so (IIRC
there were some classpath configuration problems).

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [C2]: Release Candidate 2

Posted by Per-Olof Norén <pe...@curalia.se>.
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Tuesday, November 06, 2001 10:44 AM
Subject: Re: [C2]: Release Candidate 2


> Carsten Ziegeler wrote:
> >
> > Stefano Mazzocchi wrote:
> > >
> > > Carlos wrote:
> > >
> > > > One other thing that a lot of people are having problems with
(myself
> > > > included) is the X-server requirement to use Batik in Fop. I
> > > think it would
> > > > be beneficial for end users if you could either comment the
> > > items that need
> > > > to be taken out to disable SVG or provide an alternative
> > > configuration file
> > >
> > > Good point.
> > >
> > > +1 for disabling Batik and document how to turn it on.
> > >
> > Disabling Batik is (or at least should be) very simple by not
> > including the batik jar in the lib directory when building
> > Cocoon. (I fear, currently this will not work, as the documentation
> > now needs Batik).
> > This feature of optional compilation is used for some other
> > components, too (fop, mail components etc).
> >
> > As we include batik in our cvs, the jar is in the lib directory
> > and therefore a build will include batik as well.
> > So the simple solution is to document this.
> >
> > However, I added this to the todo-list so we can see how the
> > final release will handle this.
>
> What about removing the batik generated images from the sidebar? maybe
> using the new website++ layout proposed on general@?

I´m not a committer, but here is a +1 anyways :-)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: [C2]: Release Candidate 2

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> 
> Carsten Ziegeler wrote:
> > 
> > Stefano Mazzocchi wrote:
> > >
> > > Carlos wrote:
> > >
> > > > One other thing that a lot of people are having problems 
> with (myself
> > > > included) is the X-server requirement to use Batik in Fop. I
> > > think it would
> > > > be beneficial for end users if you could either comment the
> > > items that need
> > > > to be taken out to disable SVG or provide an alternative
> > > configuration file
> > >
> > > Good point.
> > >
> > > +1 for disabling Batik and document how to turn it on.
> > >
> > Disabling Batik is (or at least should be) very simple by not
> > including the batik jar in the lib directory when building
> > Cocoon. (I fear, currently this will not work, as the documentation
> > now needs Batik).
> > This feature of optional compilation is used for some other
> > components, too (fop, mail components etc).
> > 
> > As we include batik in our cvs, the jar is in the lib directory
> > and therefore a build will include batik as well.
> > So the simple solution is to document this.
> > 
> > However, I added this to the todo-list so we can see how the
> > final release will handle this.
> 
> What about removing the batik generated images from the sidebar? maybe
> using the new website++ layout proposed on general@?
> 
Yes, that's what I thought about, too!
But for this we need someone how is able to design the stylesheet.
So volunteers are welcome!

Carsten

> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [C2]: Release Candidate 2

Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> 
> Stefano Mazzocchi wrote:
> >
> > Carlos wrote:
> >
> > > One other thing that a lot of people are having problems with (myself
> > > included) is the X-server requirement to use Batik in Fop. I
> > think it would
> > > be beneficial for end users if you could either comment the
> > items that need
> > > to be taken out to disable SVG or provide an alternative
> > configuration file
> >
> > Good point.
> >
> > +1 for disabling Batik and document how to turn it on.
> >
> Disabling Batik is (or at least should be) very simple by not
> including the batik jar in the lib directory when building
> Cocoon. (I fear, currently this will not work, as the documentation
> now needs Batik).
> This feature of optional compilation is used for some other
> components, too (fop, mail components etc).
> 
> As we include batik in our cvs, the jar is in the lib directory
> and therefore a build will include batik as well.
> So the simple solution is to document this.
> 
> However, I added this to the todo-list so we can see how the
> final release will handle this.

What about removing the batik generated images from the sidebar? maybe
using the new website++ layout proposed on general@?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: [C2]: Release Candidate 2

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> 
> Carlos wrote:
> 
> > One other thing that a lot of people are having problems with (myself
> > included) is the X-server requirement to use Batik in Fop. I 
> think it would
> > be beneficial for end users if you could either comment the 
> items that need
> > to be taken out to disable SVG or provide an alternative 
> configuration file
> 
> Good point.
> 
> +1 for disabling Batik and document how to turn it on.
> 
Disabling Batik is (or at least should be) very simple by not
including the batik jar in the lib directory when building
Cocoon. (I fear, currently this will not work, as the documentation
now needs Batik).
This feature of optional compilation is used for some other
components, too (fop, mail components etc).

As we include batik in our cvs, the jar is in the lib directory
and therefore a build will include batik as well. 
So the simple solution is to document this.

However, I added this to the todo-list so we can see how the
final release will handle this.

Carsten

> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                            able to give birth to a dancing star.
> <st...@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [C2]: Release Candidate 2

Posted by Stefano Mazzocchi <st...@apache.org>.
Carlos wrote:

> One other thing that a lot of people are having problems with (myself
> included) is the X-server requirement to use Batik in Fop. I think it would
> be beneficial for end users if you could either comment the items that need
> to be taken out to disable SVG or provide an alternative configuration file

Good point.

+1 for disabling Batik and document how to turn it on.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                           able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: [C2]: Release Candidate 2

Posted by Carlos <ca...@cvc.edu>.
One other thing that a lot of people are having problems with (myself
included) is the X-server requirement to use Batik in Fop. I think it would
be beneficial for end users if you could either comment the items that need
to be taken out to disable SVG or provide an alternative configuration file

Carlos


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org