cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: Issues left for going beta
Date Fri, 18 May 2001 09:20:19 GMT

On Thu, 17 May 2001, Sylvain Wallez wrote:

> Giacomo Pati a écrit :
> >
> > Dear Developers
> >
> > Most of the developers on Apache Cocoon 2 are willing to produce the first beta
> > very soon. I'd like to collect the showstopper issues remaining.
> >
> > A few days ago Carsten proposed the 18th of May for a beta date. No one objected
> > it but there are still issues left and my time left to do it at the moment is
> > really sparse.
> >
> > The recent discussion about Parameter forced me to have a look at all the
> > interfaces that belong to sitemap component. I've found that we need to vote on
> > the following topic.
> >
> > a) Does a Matcher need to be parameterized and thus need to expand the match
> > method of the Matcher interface with Parameters?
> >
> +1 if it makes sense. If parameters are not available where it makes
> sense, someone will inevitably need it one day. So the sooner the
> better...
> > b) The same issue is true for Selector as well. Does it need it, too?
> >
> Same as above.
> > The discussion and voting about moving the <parameter> element into the map
> > namespace will block the beta release until it's done because this is a change
> > of the sitemap syntax/semantic and we cannot do it afterward because it will
> > break backward compatability. I know that it will not be a trivial change to
> > whoever will patch the sitemap.xsl file because of some code optimation done
> > there based on namespace tests (see my recent response to Marcus Crafters
> > question about those tests).
> >
> If the vote is finished, I'll do it : I originated this and have some
> experience in namespace matters in XSL ;)

Ok, I think the voting is finished and now it's your turn to realize it
:) Can you estimate when you will have a working version of it.

> > Another issue is the production of the dists. I've made some test yesterday
> > evening and found that it is very huge (about 18M). After analysing it I've seen
> > that the source dist has all the jar twice in it. Once int the ./lib and once in
> > the ./webapp/WEB-INF/lib directory. How can/Should we reduce it?
> >
> Libs are about 7.5 Mb (15 if doubled) : Cocoon is bundled with many
> external libs and this is a perfect example of it's strength for
> integrating other components/technologies, including JSP and VBScript :)
> These libs should stay bundled with Cocoon to show its power and avoid
> endless "where can I find xxx.jar to use the xxxProducer ?" on the users
> list.

Yes, I've had no intention to remove it.

> About the duplication, couldn't the build copy the jars from ./lib to
> ./webapp/WEB-INF/lib ?

The question is should the dist be working "out of the box". Of course
you can make a "build webapp" (or a new "build setup") but then a
revision of the dist target is to become due.

> > Also there is no "binary dist" target in the build.xml yet. Well, this might not
> > be a issue for the beta-1 release.
> >
> > A few week/month ago we discussed about standardizing the namespaces we use in
> > C2. The general pattern we agreed upon was:
> >
> >
> >
> > Where APPLICATION is either "cocoon" for cocoon centric applications or "xsp"
> > for logicsheets, FOOBAR is the name of the application concern and VERSION is
> > another pattern describing the version of the application in the form
> > major.minor which are both positive integers. There have been ports of
> > logicsheets from C1 which don't respect this normation. Should we change those
> > namespaces to the pattern above or have new ones (with similar or equal
> > functionallity) sometimes after going beta?
> >
> Will we have to support old namespaces if they're not changed before
> beta ?

If we don't change the new ones introduced in C2 then yes we have to
support them. The question is mor do we need to support old ones ported
from C1 (which haa another schema)

> If yes, then change them now to avoid supporting old ones.
> > Ah, the new (the old has this as well IIRC) I18nTransformer uses a parameter
> > named src to specify the dictionary to use. I think it should be consistent with
> > all sitemap components that such values are best specified in the src attribute
> > of the transform element:
> >
> >    <map:transform type="i18n" src="dictionary.xml"/>
> >
> > And also do we realy need two of them? Are they in such a way different from
> > each other to legitimate this?
> >
> > As I've said in the beginning of this mail my time is very limited these days
> > and thus I cannot propose a date for the beta because I cannot predict when the
> > issues listed here will be fixed/realized. The 18th of May is tomorrow, so it
> > will not be realizable (uh, another Avalon interface ? :). We can shift it from
> What about the Shiftable interface ? :)
> > week to week but this doesn't makes any fun. For me and most of you this is a
> > unpleasant situation but it doesn't makes any sense to define a date for going
> > beta without seeing it really possible to make.
> >
> People will start using Cocoon as it is (sitemap, logicsheets, bundled
> components, etc), before extending it with their own components and thus
> depend on the internal APIs. So IMO, we should solve logicsheet and
> sitemap namespace issues before beta (doesn't seem to be hard work), and
> as Carsten seems to need a beta quickly, we can delay after beta passing
> parameters to matchers and selectors if this requires more time.

It's not only Carsten who is looking for a beta. There a alot of other
developers (me included) waiting for it desperately to gain more
attention for C2. Unfortunately some issues had a long time going since
those features could have been realized to reach a state for going

> Oh, and what about the recent cache issues : are they solved ? IMO they
> should be before beta.

Well, I'm not that up-to-date to answer this. Anyone else still have
cache troubles which are showstoppers?


To unsubscribe, e-mail:
For additional commands, email:

View raw message