cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: Issues left for going beta
Date Thu, 17 May 2001 13:49:57 GMT
> 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 ;)
>
> > 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.
> About the duplication, couldn't the build copy the jars from ./lib to
> ./webapp/WEB-INF/lib ?
>
> > 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:
> >
> >    http://apache.org/APPLICATION/FOOBAR/VERSION
> >
> > 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 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.
>
No, it's not me who needs a beta quickly but we, the Cocooners, need it
quickly! If we still shift it from week to week only a few hardcore people
will use. But noone else! And the aim of C2 was that it is used widely!

> Oh, and what about the recent cache issues : are they solved ? IMO they
> should be before beta.
>
As far as I know they are, I can't produce any errors and there are now
reported open issues currently.

> > So, your comments and votes :)
> >
So, speaking in Avalon terms:
+1 for Interface Realizable and -1 for Interface Shiftable


Carsten

Open Source Group                        sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de                          mailto: cziegeler@sundn.de
================================================================


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


Mime
View raw message