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 09:16:51 GMT
> Giacomo Pati wrote:
>
> 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?
>
As the parameters are available for all other components I would vote
for +1 for parameters for the matcher.

> b) The same issue is true for Selector as well. Does it need it, too?
>
As far as I know they are already implemented. So +1 for them here, too.

> 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).
>
Yes, you are right on this. So the question might be, is the effort
really worth the result or are we overdoing it here? We could move
the beta release until this is done or we could say: "Well this
approach is not bad, so leave it as it is." Regarding the problems
you mentioned above, I would suggest now, that we should simply
leave it as it is.

> 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?
>
If is not possible to reduce it, we should simply distribute it with
that size. (The bigger the archive, the more the people are impressed
about how much they get! Perhaps we could make the final release to
fill a DVD?)

> Also there is no "binary dist" target in the build.xml yet. Well,
> this might not
> be a issue for the beta-1 release.
>
Yes, I see no problems with this, too.

> 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?
>
If we can fix it in time we should change it - if not we should change
it after going beta.

> 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
> 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.
>
Yes, yes and again yes. Couldn't say it better! If we are looking
at the things listed above, there is not really much to do. I still
believe that we should give is only one more week time (shifting it
again to the 25th of may) and what is finished until then is the
beta-1. Point. There are several issues to do, I know, but we
can't shift the date week after week. If we do this, we won't have
any beta until next year, I believe. And we still could change
some things after going beta.
So here is my vote:
+10000 for a final beta one release date which will not shifted anymore.
+10000 for the 25th of may or the 1th of june.

> So, your comments and votes :)
>
> Giacomo
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message