> >> I would like to propose we remove all 'tamino-only' tests > since this > >> doesn't really give a good impression of community development. > >> [no hard feelings on the softwareAG folks, nono, just making sure > >> that this project doesn't look "owned" by SoftwareAG from the > >> outside, reducing the ability to acquire new contributors] > > > > Agreed and Peter from Software AG has shown before he > agrees to this > > as well. > > Cool. Peter, Juergen, Martin, what do you think?
Of course. The testsuite needs a little bit of hands-on in order to get freed from some Tamino-specific stuff. Unfortunately, we hadn't has a chance do do it yet. Volunteers, go ahead! > >> There is something that bugs me: Slide creates a session > in order to > >> work around WebFolders bugs in authentication. (grep for > >> getSession()) > >> I would love to have a property to disable this behavior > as I think > >> it's *very bad* that Slide is non REST-full as a whole > just to work > >> around a silly bug in IE. > >> [note Slide is currently creating a new session everytime > the client > >> doesn't have one set: this could be a potential > performance killer in > >> environments where cookies are disabled and sessions are > >> transparently cluster replicated, since each request > generates a new > >> session!] > > > > I understand this is a bad thing, but am not deep enough into the > > WebDAV layer... > > Anybody else wants to comment this before I provide a patch? Hm ... I'd love to see your patch. Does somebody know, whether the bug is in IE6 too? Regards, Peter > -----Original Message----- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 23, 2003 18:32 > To: Slide Developers Mailing List > Subject: Re: Summary and Proposals: 2.0 Release Topics > > > > On 23 Nov 2003, at 17:05, Oliver Zeigermann wrote: > > > Stefano Mazzocchi wrote: > > >> I would like to propose we remove all 'tamino-only' tests > since this > >> doesn't really give a good impression of community development. > >> [no hard feelings on the softwareAG folks, nono, just making sure > >> that this project doesn't look "owned" by SoftwareAG from the > >> outside, reducing the ability to acquire new contributors] > > > > Agreed and Peter from Software AG has shown before he > agrees to this > > as well. > > Cool. Peter, Juergen, Martin, what do you think? > > >> +1, even if we don't have any dependency on 1.3 (that I > know of), I > >> think awareness of modern JVM is a generally good trend to exhibit. > > > > My code has some dependencies on 1.3, yes, but I could > remove them... > > nah, doesn't matter, I think nobody uses 1.2 anymore. > > >> Would rephrase in "consisting of wars to be deployed in any J2EE > >> container". > > > > Hmmmm. As far as I remember, there really are some deployment > > descriptors special to Weblogic and others. > > ??? the deployment descriptors were designed to exactly avoid this > (hell, I was one of those designers). Note that we distribute cocoon > with jetty, but you can package it as a war file and install in any > j2ee container just as is. > > > I think I remember I had to change web.xml to have it run > in Weglogic, > > need to check this... > > weblogic had problems when it didn't extract the war files > and servlets > were trying to write in the file system space of the servlet context. > > >>> Another binary release will be Slide bundeled with latest > Tomcat jar > >>> from the 4.x release for download and go. > >> What will be included in the tomcat version? > > > > The wrappers stuff... > > > >> Also, I would release the client library separately. > > > > As a binary, this could work, yes. But in source, hard to > do. Did some > > reading and found out a project is not allowed to have more > than one > > CVS module... > > ?? cocoon has three. > > > So, you can checkout sources together only. > > ?? > > cvs checkout jakarta-slide/client > > would download only the client > > > Another possibility is to create a new subproject for the > client, but > > I guess this would be exaggerated, wouldn't it? > > for now, yes, I would simply suggest we move all the client stuff on > > jakarta-slide/client > > and we distribute separately that part. > > >>> - Slide 2.0beta release: 3rd-4th week of Janury 2004 > >>> - Slide 2.0final release: 3rd-4th week of February 2004 > >> I don't know how you can plan a final release, but hey > that's up to > >> you as you are the release manager ;-) > > > > Hmmm. Why not, we defined some showstoppers that must be > met. If they > > are not and/or no vote from the committers, no final > release. But, if > > things turn out well, we might not be able to fix all bugs, > but list > > them as known (if - as I said - they are minor) and still make a > > release. The remaining bugs will then be scheduled for the bugfix > > release. Does this make sense? > > Sure does. I think it's just hard to forecast the time of > this, but the > signal it gives to the community is good (even if might not > be met) so > I welcome this. > > >> Have you considered using Maven for the build system? > helps a lot in > >> those realms. > > > > Have no experience with Maven. Please explain. > > Maven is a modular project build system that works on top of > Ant. It's > ant++ for open source projects, in short. Haven't used it > myself, but I > heard it's nice and easy. take a look at http://maven.apache.org/ > > >> There is something that bugs me: Slide creates a session > in order to > >> work around WebFolders bugs in authentication. (grep for > >> getSession()) > >> I would love to have a property to disable this behavior > as I think > >> it's *very bad* that Slide is non REST-full as a whole > just to work > >> around a silly bug in IE. > >> [note Slide is currently creating a new session everytime > the client > >> doesn't have one set: this could be a potential > performance killer in > >> environments where cookies are disabled and sessions are > >> transparently cluster replicated, since each request > generates a new > >> session!] > > > > I understand this is a bad thing, but am not deep enough into the > > WebDAV layer... > > Anybody else wants to comment this before I provide a patch? > > -- > Stefano. >
