Hi! Lets move the stuff from src/contrib/webdavui into the Attic, since it does not build with current commons-httpclient, and no active part of slide requires it.
I am not a committer, so I cannot move anything... Richie Quoting Oliver Zeigermann <[EMAIL PROTECTED]>: > Stefano Mazzocchi wrote: > > I think we need a little plan of action. (of course, since I'm not an > > active committer, I don't get to vote, but at least I'll share some of > > my experience in these things). > > > > new generation number > > --------------------- > > > > From a user perspective, Slide appeared dead for too long. Doing a > > release with a 2.0 number will give the impression that things are > > changing on this regard and it's a thing that people will like, even if > > the architecture hasn't changed. > > This is what everybody thought, right? > > > > > bad marketing > > ------------- > > > > I believe Slide has currently a major bug in its own self-marketing: no > > matter how you look at it, Slide is *NOT* a content management system. > > Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) > > didn't know what a content management system was, but one thing is for > > sure: Slide is a content repository not a content management system. > > Citing from http://jakarta.apache.org/slide/index.html: > > > The Slide project main module is a Content Management and Integration > > System, which can be seen as a low-level content management > > framework. Conceptually, it provides a hierarchical organization of > > binary content which can be stored into arbitrary, heterogenous, > > distributed data stores. In addition, Slide integrates security, > > locking, versioning, as well as many other services. > > Summary: "Slide is a low-level content management framework". Doesn't > that fit your impression. > > > A CMS includes things like content authoring, content auditing, workflow > > management, presentation logic, *and* content repositories. The > > repository is only a (critical! important! vital!) piece of the CMS > > puzzle, but it's foolish to consider a content repository enough to > > implement a serious CMS. > > > > I think it's vital, for the success of a project, not to fool around > > with its own marketing. > > > > I would like to invite this community to discuss the "remarketing" of > > slide and propose "retargetting" of the project. > > > > [note: this will also make it easier to market Slide as the reference > > implementation of the JSR-170 in the future. FYI: I am the ASF > > representative for JSR-170 in the expert group] > > As I said, I can not see where Slide claims to be a full featured CMS... > > > > > solidification > > -------------- > > > > users that checkout the code for the first time, have a hard time > > understanding what parts of the code are maintained and what are not. I > > would like to propose a few things here: > > > [snip] > > > > 2) separation of the life code from the dead one. For this, the > > suggestion is the creation of a "/scratchpad" folder in the root of the > > jakarta-slide CVS module and place all dead code there. Alternatively, > > it's possible to use the existing "/proposal" folder. Candidates for > > dead code consideration are: > > > > a) the unmaintained stores > > b) the GUI for the webdav client > > > > I have set up an attic section where dead code can be moved to (and of > course moved back if it comes to life again for whatever reason). > Currently, it is empty... > > > build process > > ------------- > > > > I think users should be able to do > > > > cvs co jakarta-slide > > ant > > ./slide > > > > and get it running. The required (non-optional) jars should be included > > in the download or fetched by the build script from jar repositories > > (the only problem seems to be JTA which is under the Sun license, so we > > can't put it in CVS, but the Geronimo guys already reimplemented it > > under the apache license, so we can use that). > > As I said in another post: What should be the result of such a build? > Slide is not standalone, which probably is on of the reasons it is no > top level project. I agree (and I suppose many people agree as well) it > is desirable to have an alternative to the Tomcat environment, but I > have no idea what it may look like. > > Oliver > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------- This mail sent through the ungerground webmail system --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
