On 24 Nov 2003, at 17:20, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
On 24 Nov 2003, at 08:59, Oliver Zeigermann wrote:
I have a distribution of jetty+slide that is around 2Mb. It's bare
minimal, but very fast (boots in two seconds on my machine), but
doesn't contain any of the slide
Stefano Mazzocchi wrote:
On 24 Nov 2003, at 17:20, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
On 24 Nov 2003, at 08:59, Oliver Zeigermann wrote:
I have a distribution of jetty+slide that is around 2Mb. It's bare
minimal, but very fast (boots in two seconds on my machine), but
doesn't
Stefano Mazzocchi wrote:
On 23 Nov 2003, at 14:45, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
On 18 Nov 2003, at 02:57, Oliver Zeigermann wrote:
Summing up content from other threads:
Main question: What should a binary Slide release look like?
I understand people want something to
On 24 Nov 2003, at 08:59, Oliver Zeigermann wrote:
I have a distribution of jetty+slide that is around 2Mb. It's bare
minimal, but very fast (boots in two seconds on my machine), but
doesn't contain any of the slide admin features (they could work, but
I'm not interested in web-based
Stefano Mazzocchi wrote:
On 24 Nov 2003, at 08:59, Oliver Zeigermann wrote:
I have a distribution of jetty+slide that is around 2Mb. It's bare
minimal, but very fast (boots in two seconds on my machine), but
doesn't contain any of the slide admin features (they could work, but
I'm not
On 19 Nov 2003, at 04:20, Christopher Lenz wrote:
Oliver Zeigermann wrote:
Christopher Lenz wrote:
In every project there are areas of the code that some committers
know better than others, but that is not the same as responsibility
or ownership. If a committer that is working mostly on the
On 19 Nov 2003, at 03:43, Christopher Lenz wrote:
Stefano Mazzocchi wrote:
My personal experience shows that pointing reponsibilities creates
community fragmentation.
All the committers are responsible for all the code: if we start
asking permissions to one another to modify code in the area
On 19 Nov 2003, at 02:36, Christopher Lenz wrote:
Oliver Zeigermann wrote:
Martin Holz wrote:
robert burrell donkin [EMAIL PROTECTED] writes:
i agree with stefano's observation that whiteboard and
scratchpad
are the more usual names for this kind of thing. aligning naming
conventions isn't
On 18 Nov 2003, at 02:57, Oliver Zeigermann wrote:
Summing up content from other threads:
Main question: What should a binary Slide release look like?
I understand people want something to download and go. Store issue can
be solved without an RDBMS by using tx file store. Prolem is Slide is
Stefano Mazzocchi wrote:
On 18 Nov 2003, at 02:57, Oliver Zeigermann wrote:
Summing up content from other threads:
Main question: What should a binary Slide release look like?
I understand people want something to download and go. Store issue can
be solved without an RDBMS by using tx file
On 23 Nov 2003, at 14:45, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
On 18 Nov 2003, at 02:57, Oliver Zeigermann wrote:
Summing up content from other threads:
Main question: What should a binary Slide release look like?
I understand people want something to download and go. Store issue
Martin Holz wrote:
Richard Unger [EMAIL PROTECTED] writes:
Strong voice for 1.4 recommended, 1.3 compatibilty.
1.4 would be fine for me. But since there is
currently no feature, that really requires 1.4.,
compability with 1.3 should be kept.
Specialized stores could still use java 1.4, for
robert burrell donkin [EMAIL PROTECTED] writes:
i agree with stefano's observation that whiteboard and scratchpad
are the more usual names for this kind of thing. aligning naming
conventions isn't critical but it can help to make newbies feel at
home quicker.
Cocoon uses deprecated for old
Eric Johnson wrote:
Oliver Zeigermann wrote:
I really wonder if we have a misunderstanding here.
Perhaps so. From the perspective of a non-committer, and rare
contributor (with an ongoing consideration of adopting Slide), I would
emphasize that the project is *open source*. Since people are
Martin Holz wrote:
robert burrell donkin [EMAIL PROTECTED] writes:
i agree with stefano's observation that whiteboard and scratchpad
are the more usual names for this kind of thing. aligning naming
conventions isn't critical but it can help to make newbies feel at
home quicker.
Cocoon uses
Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
...
About this, I thought that Attic, as a name, is a bad idea
because
that conflicts with the CVS attic directory. I would
suggest to rename it to scratchpad or whiteboard as it's
done in many other ASF projects.
In what respect does it
I do not think that a official assignment is needed.
Responsibilities will evolve or are allready there (implicit).
Other os projects work as Oliver describes. But without
assignment.
Martin
Oliver Zeigermann wrote:
I really wonder if we have a misunderstanding here.
Let's consider an
Martin Dulisch wrote:
I do not think that a official assignment is needed.
Responsibilities will evolve or are allready there (implicit).
Other os projects work as Oliver describes. But without
assignment.
Agreed. This is *not* official, but rather for *orientation* of all :)
Oliver
Martin
Am Mittwoch, 19. November 2003 09:23 schrieb Martin Dulisch:
Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
...
About this, I thought that Attic, as a name, is a bad idea
because
that conflicts with the CVS attic directory. I would
suggest to rename it to scratchpad or whiteboard
Christopher Lenz wrote:
Oliver Zeigermann wrote:
Martin Holz wrote:
robert burrell donkin [EMAIL PROTECTED] writes:
i agree with stefano's observation that whiteboard and scratchpad
are the more usual names for this kind of thing. aligning naming
conventions isn't critical but it can help to
As it seems to be clear by now there will be a 2.0 release. This
includes there will be milestone releases before the final one which
will be available as binaries *in pricipal*.
The problem for me is what a Slide binary release may look like... I
have seen the 1.0.x binary comes as a Tomcat
For the release and also for the people contributing questions or
patches there should be someone to address directly for each part of the
code.
At least for the stores, the client, the webdav layer and of course the
kernel there must be at least one committer in charge.
Responsibilities I
What JDK should be supported in the 2.0 relase?
My proposal: JDK1.3 required, JDK1.4 recommended as JDK1.2 or less are
hardly used in serious server applications, am I wrong? Anyway if JDK1.2
is aimed to I would need to make slight modifications of my tx file
store, but it should be possible.
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
Hi Robert, hi all,
I have a hard time figuring out how to update the docs. While I seem to
have found out how to actually deploy modified pages on the web server I
suspect, those pages in the Slide pages are not native HTML, but
generated from the real source. I really tried to find out on
Hi Oliver,
the actual source for the docs are in [src/doc], and are XSL-transformed
by the Ant doc target into the [docs] directory. IIRC, the whole
process is:
- modify the documents in [src/doc]
- make the transformation using ant doc
- commit the changes in the [docs] directory
- login
Chritopher,
thanks a lot! That's what I was looking for!
Oliver
Christopher Lenz wrote:
Hi Oliver,
the actual source for the docs are in [src/doc], and are XSL-transformed
by the Ant doc target into the [docs] directory. IIRC, the whole
process is:
- modify the documents in [src/doc]
-
Summing up content from other threads:
Main question: What should a binary Slide release look like?
I understand people want something to download and go. Store issue can
be solved without an RDBMS by using tx file store. Prolem is Slide is
not standalone and can only be used with a web
[snip...]
My favorit issues are:
- Getting the stores to work as expected (at least file/db-stores)
this is critical, yes.
- Implement internal locking (should not be transactional)
can you tell us more about this?
I think we need two different types of locks in slide: First there are
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
Hi!
Strong voice for 1.4 recommended, 1.3 compatibilty.
I feel confident 1.2 can be dropped, I don't know of any important production
systems that don't have at least a 1.3 runtime.
What Servlet Spec level do we require? 2.2? 2.3? I would vote for 2.3, but this
does exclude weblogic6 and
As it seems to be clear by now there will be a 2.0 release. This
includes there will be milestone releases before the final one which
will be available as binaries *in pricipal*.
Shall we set a date? Mid January - Release Candidate 1?
The problem for me is what a Slide binary release may
Richard Unger [EMAIL PROTECTED] writes:
Strong voice for 1.4 recommended, 1.3 compatibilty.
1.4 would be fine for me. But since there is
currently no feature, that really requires 1.4.,
compability with 1.3 should be kept.
Specialized stores could still use java 1.4, for example
to see, if
Hi!
I need filters for my stuff too, but slide doesn't so I suppose we could
reach Servlet 2.2 compatibility.
I just don't like Servlet 2.2, having lots of problems with weblogic6 at
work at the moment...
Richie
On Tue, 2003-11-18 at 15:37, Martin Holz wrote:
Richard Unger [EMAIL PROTECTED]
On 18 Nov 2003, at 01:41, Oliver Zeigermann wrote:
What JDK should be supported in the 2.0 relase?
My proposal: JDK1.3 required, JDK1.4 recommended
+1
--
Stefano.
smime.p7s
Description: S/MIME cryptographic signature
My personal experience shows that pointing reponsibilities creates
community fragmentation.
All the committers are responsible for all the code: if we start asking
permissions to one another to modify code in the area where others
people is responsible, the development performance drops.
On 18 Nov 2003, at 01:56, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
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
Hmmm. I thought it might be impolite to mess around in other peoples code...
But if this is what people want, it is ok with me...
Is this what people want? Opinions, please!
Oliver
Stefano Mazzocchi wrote:
My personal experience shows that pointing reponsibilities creates
community
Stefano Mazzocchi wrote:
On 18 Nov 2003, at 01:56, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
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
On 18 Nov 2003, at 19:01, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
On 18 Nov 2003, at 01:56, Oliver Zeigermann wrote:
snip
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...
+1
one4all + all4one :)
IMHO it's healthier to discuss any changes that you feel might step on
others toes or that are controversial on the list before you make them.
this gives not only the other committers a chance to join in but also
the development community hanging around on the list.
-
I really wonder if we have a misunderstanding here.
Let's consider an example: I certainly have no real idea of the guts of
Peter's code and he hardly has of mine. That's fine as we both have our
stuff to concentrate on. Now, when there is a bug in Peter's code I turn
to Peter and ask him to
Oliver Zeigermann wrote:
I really wonder if we have a misunderstanding here.
Perhaps so. From the perspective of a non-committer, and rare
contributor (with an ongoing consideration of adopting Slide), I would
emphasize that the project is *open source*. Since people are not
getting paid to
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
Daniel Florey wrote:
It's nice to have you around on this list Stefano, you're able to point out
things very clearly.
Thanks.
I'm propagating the idea of moving from a CMS to
something like a CMF in our company for quite a while.
But I think that Slide should be more than just a content
On Sat, 2003-11-15 at 01:05, Stefano Mazzocchi wrote:
On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
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
Well, the CVS Head should have at least integration quality, if not
production, IMHO.
How is anyone supposed to get things running if it the HEAD represents
some undeterminate development state?
Whether the build/run should be as simple as stefano describes is
another question...
Richie
On
Stefano Mazzocchi wrote:
On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
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
Stefano hit the nail on the head with Look around. I believe that
there are at least three requirements for the Slide 2.0 release and
other enhancements that will make Slide much more attractive and
therefore attract many more talented people to contribute which is what
we all want to see.
Mike Oliver wrote:
#1 I believe it is less than desireable to require jars to be moved out
of the webapp and into Tomcat's commons for a lot of reasons, not the
least of which is the compatibility of other webapps and classpath
problems (with other webapps on that same Tomcat) you introduce by
OK. Will do so!
Thanks Robert, I need you all the help I can get :)
Oliver
robert burrell donkin wrote:
the dev list is usually considered the right place for discussions about
releases. certainly, all VOTEs must take place on the dev list. any
release will mean several VOTEs usually
[COPIED FROM USERS LIST, THIS IS HERE IN THE DEV LIST IS THE RIGHT POST
TO FOLLOW UP]
Hi everyone!
I understand those votes from active committers which are
+1 from Martin
+1 from Ingo
+1 from Peter
mean:
1. We actually should start a release process now
2. I should be the release manager
If
On 13 Nov 2003, at 21:52, robert burrell donkin wrote:
the dev list is usually considered the right place for discussions
about releases. certainly, all VOTEs must take place on the dev list.
any release will mean several VOTEs usually starting with a release
plan and the election (often by
On 14 Nov 2003, at 08:23, Oliver Zeigermann wrote:
[COPIED FROM USERS LIST, THIS IS HERE IN THE DEV LIST IS THE RIGHT
POST TO FOLLOW UP]
Hi everyone!
Hi!
I understand those votes from active committers which are
+1 from Martin
+1 from Ingo
+1 from Peter
mean:
1. We actually should start a
Stefano Mazzocchi wrote:
...
1) clear separation of the server part from the client part.
When you download the slide CVS, you get server and client at
the same time,
with the same build, docs and all that. I think we should
clearly separate those things out. Potentially, in the future,
Hi,
as slide seems to gain more and more interest over the last weeks I'd like to
add some comments to this issue.
Our company has implemented a full featured CMS in the past few years that
works with a self implemented content repository. Beside the repository we
implemented a presentation
On 14 Nov 2003, at 17:07, Daniel Florey wrote:
Hi,
as slide seems to gain more and more interest over the last weeks I'd
like to
add some comments to this issue.
appreciated.
Our company has implemented a full featured CMS in the past few years
that
works with a self implemented content
Stefano Mazzocchi wrote:
[snip]
1) clear separation of the server part from the client part. When you
download the slide CVS, you get server and client at the same time,
with the same build, docs and all that. I think we should clearly
separate those things out. Potentially, in the future,
Stefano Mazzocchi wrote:
On 14 Nov 2003, at 08:23, Oliver Zeigermann wrote:
[COPIED FROM USERS LIST, THIS IS HERE IN THE DEV LIST IS THE RIGHT
POST TO FOLLOW UP]
Hi everyone!
Hi!
I understand those votes from active committers which are
+1 from Martin
+1 from Ingo
+1 from Peter
mean:
1. We
On 14 Nov 2003, at 18:41, Remy Maucherat wrote:
\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)
Stefano Mazzocchi wrote:
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
On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote:
Stefano Mazzocchi wrote:
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
For everyone subscribed to the dev list only: Discussion about the new
release has been started in the user list. Please keep the discussion in
that list.
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
the dev list is usually considered the right place for discussions
about releases. certainly, all VOTEs must take place on the dev list.
any release will mean several VOTEs usually starting with a release
plan and the election (often by lazy acclamation) of the release
manager.
so, it's
64 matches
Mail list logo
