> Giacomo Pati wrote:
> 
> Here we are to see how the issues are:
> 
> On Fri, 18 May 2001, Carsten Ziegeler wrote:
> 
> > I think we agreed on the following changes:
> >
> > 1. map namespace for parameters (changes the sitemap definition)
> >    Volunteer: Sylvain
> >    Finished : 22rd May
> 
> done
> 
> > 2. Optional SAXConnectors (changes internal content aggregation)
> >    Volunteer: Carsten
> >    Finished : 23rd May
> 
> done
> 
> > 3. Redesign of the EntityResolver/URL handling
> >    (changes the pipeline components interface)
> >    Volunteer: Carsten
> >    Finished : 23rd of May (hopefully)
> 
> done (?)
> 
The major part is done. Regarding a beta version this is OK.
There are some minor issues if we want to add the cocoon: urls,
but hopefully this doesn't affect any interfaces.
So we could regard this as done.

The fix for the TraxTransformer is finished, but currently
my cvs is not working properly, so i can't check in.
Hope I can solve this today...

> > 4. Remove the X/CIncludeSAXConnectors and make transformers
> >    Volunteer:
> >    Finished :
> >    This transformers are not really required for the beta, I think
> 
> outstanding, not relevant for beta (?)
> 
Yes, I will (if cvs is working) remove the X/CIncludeSAXConnectors
and readd the NullSAXConnector. Then this is solved for the beta.

> > 5. Parameters for Matchers/Selectors (I think there was no vote "-1")
> >    (changes the pipeline components interface)
> >    Volunteer :
> >    Finished  :
> 
> done
> 
> > 6. Change the Namespace for the taglibs to the standard
> >    Volunteer :
> >    Finished  :
> 
> done
> 
> > 7. Administration tasks for making the release
> >    Here we should collect what has to be done.
> 
> This should be discussed. My questions (still) are:
> 
> - how should the dist be structured?
> 
>   As I've already explained the build target "dist" has all the jars
>   twice in final tgz/zip file this is a duplication amount of about 8MB
> 
Personally I am not sure about the dist, because this is then a prebuild
version for the servlet api 2.2. The users have to rebuild for the servlet
api 2.3 and if they want to use additional features, e.g. php, j2ee.

So can't we simply pack the cvs tree as the distribution?

> - how should further development take place concerning cvs tagging
> 
> a)
>        +- V2_0B1
>        !+- V2_1_dev
>        Vv
> -------+---------------------------+--------------> HEAD
>        !                           A
>        !   +- V2_0B2  +- V2_0RC1   ! Join
>        !   V          V            !
>        +---+----------+------------+ V2_0
> 
> b)
>        +- V2_0B1  +- V2_0B2  +- V2_0RC1  +- V2_0
>        V          V          V           V
> -------+----------+----------+-----------++-------> HEAD
>        !                                  A
>        !                                  ! Join
>        !                                  !
>        +----------------------------------+ v2_1_dev
> 
> c)
>        +- BETA1   +- BETA2   +- RC1   +- REL_2_0
>        V          V          V        V
> -------+----------+----------+--------+-----------> HEAD
> 
> Comments to the variations above:
> 
> a) The advantage of a this approach is that 2.1 development can
>    start as soon as the beta1 is out. The disadvantage is that we have
>    to deal with a separate branch for the 2.0 release.
> 
> b) This is the revers of a). The head branch is always in synch with the
>    latest announced release and 2.1 development starts on a separate
>    branch instead on the head branch.
> 
> c) The advantage of this approach is its simple straight way of release
>    handling. On the other hand development of a 2.1 release can not be
>    started until the 2.0 release is out.
> 
Although we can't start with 2.1 before we released 2.0 it is easier to 
maintain, so I vote +1 for c).
I think we will have to change some parts of C2 before the final release
and it might be difficult to maintain this.

> >
> > As far as I know this is it. Or did I miss something?
> 
> I'd like to have at least our own samples to work correctly for a beta.
> After testing all samples and browsing through the log I have some
> suggestions/corrections to discuss:
> 
> - can we comment out the force-load element in the web.xml deployment
>   descriptor to reduce the number of exceptions thrown (even if it's
>   only a WARN).
> 
Agree.

> - can we make Batik act nicer? It's throwing alot of Exceptions which
>   might be because it was not designed to run in a server/servlet
>   environment or we use it the wrong way? Is anyone on the batik list
>   or more familiar with it? Batik starts with a TranscoderException
>   encloseing a null Exception and one that states "Connection reset
>   by peer". Any suggestions?
> 
> - the "Simple Internationalization" sample doesn't work (throws a
>   NPException back to the browser which is very bad for a sample). Can
>   someone correct that?
> 
> - the "XSP Internationalization" samples throws a NPE in the logs but
>   seems to work at the browser. However the links in the pages to the
>   different language samples don't work for me. Correction is needed.
> 
> After discussion and solving the issues in this mail I'll preserv some
> time next week to put the beta out.
> 
Great !!

Carsten
> Giacomo
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to