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.
I don't know how you can plan a final release, but hey that's up to you as you are the release manager ;-)- Slide 2.0beta release: 3rd-4th week of Janury 2004 - Slide 2.0final release: 3rd-4th week of February 2004
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.
smime.p7s
Description: S/MIME cryptographic signature
