You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jh...@virbus.de> on 2003/11/24 19:04:47 UTC
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml
index.xml
On 24.11.2003 18:40, reinhard@apache.org wrote:
> reinhard 2003/11/24 09:40:41
>
> Modified: src/documentation/xdocs book.xml index.xml
> Added: src/documentation/xdocs features.xml
> Log:
> - add features list from http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
> to CVS
Cool. I guess it's the first content moved from Wiki to CVS.
Joerg
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml
Posted by Upayavira <uv...@upaya.co.uk>.
gounis@osmosis.gr wrote:
>so why not start to rate wiki pages so if anyone want to do something
>start with most wanted pages ?
>
>
It is simpler than that.
A page gets into the CVS when someone wants to put it there. So if you
think a page should be in the CVS, then suggest it here, and if it seems
generally appropriate, produce the necessary patch, and someone'll
commit it.
Compare the workload for a committer for converting a wiki doc into
xdocs to the work for simply committing a patch. Far less. Provide
patches (after a little discussion) and you may well find them committed.
Regards, Upayavira
>-- stavros
>
>
>On Mon, 24 Nov 2003, Joerg Heinicke wrote:
>
>
>
>>On 24.11.2003 20:27, gounis@osmosis.gr wrote:
>>
>>
>>
>>>how is marked that a wiki page is ready to move to CVS?
>>>
>>>
>>I guess almost every page has valuable content to be moved to the CVS.
>>The only question is: Who does the work? Reinhard simply started with
>>the maybe most wanted page for the official documentation. If someone
>>else provides other pages we are glad to add it to the CVS.
>>
>>Joerg
>>
>>
>>
>>
>
>
>
>
Re: Linotype and RealPathModule
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.12.2003 12:17, Stefano Mazzocchi wrote:
>> From a logical view the new behaviour of Jetty makes sense, at least
>> for consistency:
>>
>> / D:\cocoon-2.1\build\webapp
>> /images D:\cocoon-2.1\build\webapp\images
>> /WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF
>>
>> while it was "D:\cocoon-2.1\build\webapp\" until now.
>
>
> that's probably why they fixed it.
>
>> Shall we remove all trailing path separators?
>
>
> what is the behavior of tomcat? that is considered the reference
> implementation.
Unfortunately "D:\cocoon-2.1\build\webapp\".
So it's more a simple root + accessor:
root = "D:\cocoon-2.1\build\webapp"
accessor value
/ D:\cocoon-2.1\build\webapp\
/images D:\cocoon-2.1\build\webapp\images
/WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF
Hmm, also not that illogical.
I suggest to always remove the trailing path separator in the
RealPathModule. Any comments?
Joerg
Re: Linotype and RealPathModule (was: Doco needs landing)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 2 Dec 2003, at 03:52, Joerg Heinicke wrote:
> On 29.11.2003 17:02, Stefano Mazzocchi wrote:
>
>>> I don't mean to be cynical or anything, but Linotype and Portal
>>> landed in Cocoon as more-or-less functional things and not much
>>> has happened since.
>> wait a full second, David. I can't talk for Portal-oriented stuff
>> since I don't use it, but for linotype, it was ported to be
>> IE5/mozilla cross-platform, I received a few patches and Joerg is
>> patching it to fix jetty problems and there were discussions about
>> integration with cocoon forms and Lenya.
>
> Did I promised it? :-)
>
> I recommended Linotype to two persons here managing their private club
> website news. Otherwise these both persons (= software developer) have
> to do all the changes in static HTML pages, at least this way it was
> done until now. If they choose this approach (what about hosting and
> so on ...) the editor base is bigger, less work for them. So Linotype
> is not unused or dead - it works. Probably nothing will come back to
> Cocoon from these two persons, but who knows - bug reports are also
> welcome.
The plan is to move the xhtml editing behavior in Cocoon Forms. That
will give a lot more exposure and potentially more bug reports, feature
requests and patches.
> The problem with the realpath I came across when testing the first
> trials (they worked on one system, but not on another one - endorsed
> libs again). I have no problem fixing the realpath problem using my
> pseudo code (if !ends with '/') and so on, but I would like to know
> what's correct in the servlet spec sense? I read across it, but didn't
> find any further mentioning besides realpath exists. Do Tomcat and
> Jetty 4.2.9 behave correctly or Jetty 4.2.14? And is it something to
> be fixed in Linotype or in the realpath module? I don't want to add a
> simple hack to circumvent other's problems.
>
> From a logical view the new behaviour of Jetty makes sense, at least
> for consistency:
>
> / D:\cocoon-2.1\build\webapp
> /images D:\cocoon-2.1\build\webapp\images
> /WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF
>
> while it was "D:\cocoon-2.1\build\webapp\" until now.
that's probably why they fixed it.
> Shall we remove all trailing path separators?
what is the behavior of tomcat? that is considered the reference
implementation.
--
Stefano.
Linotype and RealPathModule (was: Doco needs landing)
Posted by Joerg Heinicke <jo...@gmx.de>.
On 29.11.2003 17:02, Stefano Mazzocchi wrote:
>> I don't mean to be cynical or anything, but Linotype and Portal
>> landed in Cocoon as more-or-less functional things and not much
>> has happened since.
>
>
> wait a full second, David. I can't talk for Portal-oriented stuff since
> I don't use it, but for linotype, it was ported to be IE5/mozilla
> cross-platform, I received a few patches and Joerg is patching it to fix
> jetty problems and there were discussions about integration with cocoon
> forms and Lenya.
Did I promised it? :-)
I recommended Linotype to two persons here managing their private club
website news. Otherwise these both persons (= software developer) have
to do all the changes in static HTML pages, at least this way it was
done until now. If they choose this approach (what about hosting and so
on ...) the editor base is bigger, less work for them. So Linotype is
not unused or dead - it works. Probably nothing will come back to Cocoon
from these two persons, but who knows - bug reports are also welcome.
The problem with the realpath I came across when testing the first
trials (they worked on one system, but not on another one - endorsed
libs again). I have no problem fixing the realpath problem using my
pseudo code (if !ends with '/') and so on, but I would like to know
what's correct in the servlet spec sense? I read across it, but didn't
find any further mentioning besides realpath exists. Do Tomcat and Jetty
4.2.9 behave correctly or Jetty 4.2.14? And is it something to be fixed
in Linotype or in the realpath module? I don't want to add a simple hack
to circumvent other's problems.
From a logical view the new behaviour of Jetty makes sense, at least
for consistency:
/ D:\cocoon-2.1\build\webapp
/images D:\cocoon-2.1\build\webapp\images
/WEB-INF D:\cocoon-2.1\build\webapp\WEB-INF
while it was "D:\cocoon-2.1\build\webapp\" until now.
Shall we remove all trailing path separators?
Joerg
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 2 Dec 2003, at 11:03, Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote:
>> On 1 Dec 2003, at 08:26, Nicola Ken Barozzi wrote:
>>> What I don't really understand is that he is not using a public
>>> Apache repository, like the Cocoon scratchpad, to do it.
>> I am!!!
>
> Yes, sorry for misunderstanding.
>
> As I tried to say I'm +1 to your work all the way, and was just
> puzzled by the apparent closeness of the code. I'm happy to be proved
> wrong.
:-)
> Stefano Mazzocchi wrote:
>
> > On 1 Dec 2003, at 15:01, Nicola Ken Barozzi wrote:
> >
> >> I think that creating a doco@apache.org mailing list, similar to
> >> repository@apache.org could create a nice space where all these
> >> projects and even others can discuss things without cross posting.
> >
> > not yet. it's too much vaporware now. I shouldn't have come up with
> > the plan before having something to show.
> >
> > Damn me.
>
> Well, you let the cat out of the bag, and IMHO if you keep on saying
> "I'm working on it" this discussion, that has now been cleared, will
> probably and unfortunately start again.
Very true. I'll shut up until I have something to show ;-)
> Why don't you add "Doco" to this page http://cvs.apache.org/~stefano/
> with a reference to the JSPwiki page about it? At least we have
> something to point to when others ask.
I will do that.
> Thanks for your work on it, it's really really appreciated. :-)
You are welcome. The more serious rationale behind this will come up
soon, but hey, no more cats out of the bags for now ;-)
--
Stefano.
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
>
> On 1 Dec 2003, at 08:26, Nicola Ken Barozzi wrote:
>
>> What I don't really understand is that he is not using a public Apache
>> repository, like the Cocoon scratchpad, to do it.
>
> I am!!!
Yes, sorry for misunderstanding.
As I tried to say I'm +1 to your work all the way, and was just puzzled
by the apparent closeness of the code. I'm happy to be proved wrong.
Stefano Mazzocchi wrote:
> On 1 Dec 2003, at 15:01, Nicola Ken Barozzi wrote:
>
>> I think that creating a doco@apache.org mailing list, similar to
>> repository@apache.org could create a nice space where all these
>> projects and even others can discuss things without cross posting.
>
> not yet. it's too much vaporware now. I shouldn't have come up with
> the plan before having something to show.
>
> Damn me.
Well, you let the cat out of the bag, and IMHO if you keep on saying
"I'm working on it" this discussion, that has now been cleared, will
probably and unfortunately start again.
Why don't you add "Doco" to this page http://cvs.apache.org/~stefano/
with a reference to the JSPwiki page about it? At least we have
something to point to when others ask.
Thanks for your work on it, it's really really appreciated. :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Dec 2003, at 08:26, Nicola Ken Barozzi wrote:
> What I don't really understand is that he is not using a public Apache
> repository, like the Cocoon scratchpad, to do it.
I am!!! I'm sending back the patches to slide everytime I make one. I
was nominated for committership in Slide and hopefully I will be voted
in.
Next step is the repository block and this happens here in cocoon. I
already sent an email about it.
Doco is growing bottom up.
After the repository block is done, I plan to move Linotype to use the
repository block and the code will get back in cocoon cvs.
After that, I plan to move the xhtml editor of linotype into Cocoon
Forms. This will happen in cocoon cvs again.
then will move lenya to use cocoon forms and flow, this will happen in
lenya cvs (but probably on a branch or /proposal/ not to stop lenya
from growing)
then will write the mailets for the mail workflow, this will happen in
james cvs (but I'm not committer there)
etc.. etc..
please understand that I'm doing everything in the open. I'll try to
come up with a "implementation plan" so that people know what stage I
am in... but the problem is that each stage depends on the previous, so
there is no parallelization possible... this is why I said separating
phases is going to slow things down. there is not much code to write,
it's already there, it just needs to be polished.
but there is *NO* single line of code that isn't already back in the
CVS repositories or is going to be there.
Doco is still a long way, people. We have the pieces, but they are
rough, we need to polish them first. and this is what I'm doing. One
piece at the time.
--
Stefano.
Re: Doco needs landing
Posted by Steven Noels <st...@outerthought.org>.
On Dec 1, 2003, at 2:14 PM, David Crossley wrote:
> Nicola Ken Barozzi wrote:
>>> David Crossley wrote:
>> ...
>>>> What is worrying is that this one-person thing (though i trust
>>>> Stefano to know what to do) will have no community to land in
>>>> and Apache will spawn yet another new project.
>>
>> Well, Doco ahould be a glue that it to put together different projects
>> in a coherent vision. We have Slide (backend), Lenya (CMS), Forrest
>> (presentation).
>
> It sounds like it will be a new project outside of the
> Cocoon/Slide/Lenya/Forrest projects. Fair enough, that might
> be the best solution. But where is the planning to enable that?
There is none, at least not in a formalized sense, but that shouldn't
be a problem. I'm currently balancing between a) we should require
every more-than-trivial code donation to go through the Incubator, not
for IP issues (which I doubt would ever emerge from our own dear
Stefano), but to make sure community-building is not an afterthought,
and b) "OK, let's see what Darwin does with it" attitude. Planning
won't help much, IMHO, it's just the PMC which needs to decide which
way it wants to go: do we need more code a possibly interested
community could come for and play with, or do we try to flesh out a
community before, which might ensure a better longevity of the code.
Either case, I still believe things just happen, and we should be
reactive and decisive enough to make the best out of this, by actively
(re)structuring the Cocoon project (as a whole) towards optimal
community cohesion, while still providing breathing space for the
different subcommunities.
The fact Doco has an ASF-wide appeal doesn't simplify this equation,
although to its own benefit IMHO. Forrest is technically also
intricately linked to Cocoon, still its community of users is wildly
different - so offering cross-codebase commit access was perhaps the
better idea rather than actively trying to subsume Forrest in the
Cocoon hemisphere. Ditto with Doco: it might be linked to Cocoon, if
only by its creator, and no doubt also because of technical reasons,
but still it might warrant its own development community in the future.
Frankly, I think we should get our act together on other issues (Rhino
reintegration, Fortress, Blocks 2.2, project guidelines, splitting of
some blocks in effective subprojects, and some light weeding of code
cruft) before trying to grow the Cocoon organizational structure beyond
what we have now (by providing anything else than a technical landing
zone for Doco). But that's IMHO and just my intellectual exercise -
please take it as is.
Also, I think Stefano just needs a bit more time to come up with
something sufficiently designed and fleshed out so that others *can*
collaborate on it, which is exactly the same as happened with Woody:
there were three, maybe four weeks of intense, behind-closed-doors and
silent thinking, designing and coding, before there was a first code
drop in the public repository. I'm not going to evangelize this method
of contributing for all future contributions, but sometimes people need
to be able to get down with their head and get some real work done, in
order to let others join successfully. This, IMHO, is the holy grail of
Open Source development: moving forward while not claiming the entire
"thoughtspace" and design, so that others feel both welcome *and*
capable to join.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Doco needs landing
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Dec 2003, at 15:01, Nicola Ken Barozzi wrote:
> I think that creating a doco@apache.org mailing list, similar to
> repository@apache.org could create a nice space where all these
> projects and even others can discuss things without crossposting.
not yet. it's too much vaporware now. I shouldn't have come up with the
plan before having something to show.
Damn me.
--
Stefano.
Re: Doco needs landing
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Nicola Ken Barozzi wrote:
>
>>>David Crossley wrote:
...
> My concern was not necessarily that Forrest should be doing it,
> but rather that Forrest was born to do that, then lost its people,
> then had to modify its dreams. Let us get it right this time.
Well, this is not exactly how I see it. Forrest lost its people? Where?
What happened IMHO is that the frontend part was so "big" to do properly
that Forrest had to simply concentrate on that. The rest came by itself,
and we are still concentrating on that part. With afterthought it seems
logical that there is a core group that concentrates on what Forrest now
is doing.
...
> The initial proposal was copied to many different
> lists and it is hard to follow.
Hmmm...
...
> You say "land here" .... Where? In Cocoon? Is it just a block maybe?
Till I see it, I really can't say.
In any case, this is Stefano's tentative. If it fails (and I don't think
it will), others can easily try again. If others want to give him a hand
say so, and he will surely use some help. Personally I don't have time
and motivation to do what he is doing, nor the skill actually, so from
my POV whatever he does is ok, and I'll just see what to do when it
"lands". I could see a problem if/when others want to actively help but
even after asking him cannot, but I don't see this happening.
I think that creating a doco@apache.org mailing list, similar to
repository@apache.org could create a nice space where all these projects
and even others can discuss things without crossposting.
For example Stefano could use it to post advancements of his efforts or
make cross-list questions.
Whattadathink?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Doco needs landing
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
> >David Crossley wrote:
> ...
> >> What is worrying is that this one-person thing (though i trust
> >> Stefano to know what to do) will have no community to land in
> >> and Apache will spawn yet another new project.
>
> Well, Doco ahould be a glue that it to put together different projects
> in a coherent vision. We have Slide (backend), Lenya (CMS), Forrest
> (presentation).
It sounds like it will be a new project outside of the
Cocoon/Slide/Lenya/Forrest projects. Fair enough, that might
be the best solution. But where is the planning to enable that?
> Look at the Forrest community now. Do you think we are ready and willing
> to lead such a design? Speaking for me, not now, I still have lots of
> work to do on what Forrest does now.
My concern was not necessarily that Forrest should be doing it,
but rather that Forrest was born to do that, then lost its people,
then had to modify its dreams. Let us get it right this time.
Anyway, the Forrest community really does have all the Cocoon
committers too. So it could be done there if that was the
appropriate place.
> To be honest, Stefano has already told us about it and already got
> feedback from all these projects, so in fact he is already working with
> our ACK. Furthermore, there is no decision yet about where to place it,
> or even if it will ever be something autonomous.
That was what i was getting at in the beginning of this thread.
Where will it live? Where can we talk about it and help to guide
and build it? The initial proposal was copied to many different
lists and it is hard to follow.
> What I don't really understand is that he is not using a public Apache
> repository, like the Cocoon scratchpad, to do it. At least we could have
> watched it grow, and he would have not been "slowed" with "community" as
> he now likes to say ;-) In any case, he's free to do so if he wishes,
> and we will see what to do when this thing will land here.
You say "land here" .... Where? In Cocoon? Is it just a block maybe?
--David
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Dec 2003, at 09:16, Gianugo Rabellino wrote:
> Nicola Ken Barozzi wrote:
>
>> What I don't really understand is that he is not using a public
>> Apache repository, like the Cocoon scratchpad, to do it. At least we
>> could have watched it grow, and he would have not been "slowed" with
>> "community" as he now likes to say ;-) In any case, he's free to do
>> so if he wishes, and we will see what to do when this thing will land
>> here.
>
> I understand that there is no such thing as code now. From a few
> online/RL chats and the emails I'm reading, I gather that until now
> Stefano has been busy testing all the possible DAV server/client
> combinations on earth, patching them and earning committership on
> Slide while at it :-), but so far with not a single Cocoon-specific
> line of code. I'm pretty sure that as soon as there is something more
> Cocoon related we'll start to see RTs (we already had one yesterday)
> and code.
Precisely!!!
BTW, just in order to choose which repository to use and to invest my
effort on, I spent a few weeks.
This might not get you a single line of code, but might benefits other
people and polarize communities toward a common goal.
If this is not useful, I don't know what is.
--
Stefano.
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Gianugo Rabellino <gi...@apache.org>.
Nicola Ken Barozzi wrote:
>
> What I don't really understand is that he is not using a public Apache
> repository, like the Cocoon scratchpad, to do it. At least we could have
> watched it grow, and he would have not been "slowed" with "community" as
> he now likes to say ;-) In any case, he's free to do so if he wishes,
> and we will see what to do when this thing will land here.
>
I understand that there is no such thing as code now. From a few
online/RL chats and the emails I'm reading, I gather that until now
Stefano has been busy testing all the possible DAV server/client
combinations on earth, patching them and earning committership on Slide
while at it :-), but so far with not a single Cocoon-specific line of
code. I'm pretty sure that as soon as there is something more Cocoon
related we'll start to see RTs (we already had one yesterday) and code.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Michael Wechner wrote:
> Nicola Ken Barozzi wrote:
>
...
[about doco]
> it's not CVS or SVN yet, but AFAIK Stefano updated recently
>
> http://wiki.cocoondev.org/Wiki.jsp?page=Doco
Excellent! :-)
Thanks Michael for reporting.
And thanks Stefano for writing it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Michael Wechner <mi...@wyona.com>.
Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote:
>
>> On 28 Nov 2003, at 03:46, David Crossley wrote:
>
>
> What I don't really understand is that he is not using a public Apache
> repository, like the Cocoon scratchpad, to do it.
it's not CVS or SVN yet, but AFAIK Stefano updated recently
http://wiki.cocoondev.org/Wiki.jsp?page=Doco
HTH
Michi
At least we could have
> watched it grow, and he would have not been "slowed" with "community" as
> he now likes to say ;-) In any case, he's free to do so if he wishes,
> and we will see what to do when this thing will land here.
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
> On 28 Nov 2003, at 03:46, David Crossley wrote:
...
>> Mmmm, i am not sure that i like this approach. "Doco" sounds
>> to me like one of the reasons that "Forrest" was started.
>
> that's right, but forrest took a different path and now focuses on
> static generation of web sites, full blown content management is not at
> reach there anymore.
Although we have currently decided to focus on the final generation step
(not only CLI, but still the last presentation step), of course it does
not mean that Doco could not be a part of Forrest.
I mean *could* not *should*.
ATM Doco is so virtual that I cannot say anything about it.
>> What is worrying is that this one-person thing (though i trust
>> Stefano to know what to do) will have no community to land in
>> and Apache will spawn yet another new project.
Well, Doco ahould be a glue that it to put together different projects
in a coherent vision. We have Slide (backend), Lenya (CMS), Forrest
(presentation).
Look at the Forrest community now. Do you think we are ready and willing
to lead such a design? Speaking for me, not now, I still have lots of
work to do on what Forrest does now.
To be honest, Stefano has already told us about it and already got
feedback from all these projects, so in fact he is already working with
our ACK. Furthermore, there is no decision yet about where to place it,
or even if it will ever be something autonomous.
What I don't really understand is that he is not using a public Apache
repository, like the Cocoon scratchpad, to do it. At least we could have
watched it grow, and he would have not been "slowed" with "community" as
he now likes to say ;-) In any case, he's free to do so if he wishes,
and we will see what to do when this thing will land here.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Doco needs landing
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Dec 2003, at 03:27, David Crossley wrote:
> Stefano Mazzocchi wrote:
>> David Crossley wrote:
>>
>>> Mmmm, i am not sure that i like this approach. "Doco" sounds
>>> to me like one of the reasons that "Forrest" was started.
>>
>> that's right, but forrest took a different path and now focuses
>> on static generation of web sites, full blown content management
>> is not at reach there anymore.
>
> That is a rash statement from afar.
>
> Forrest was started by some visionaries with grand plans.
> After a very short while, most of those people disappeared
> and only a few committers remained to assist the fledgling.
>
> Forrest documentation still talked about the grander plans.
> Brilliant though it is, Forrest had to pull its horns in,
> as it was not yet delivering on that vision.
>
> So certain dreams had to be "shelved". Not abandoned, just put on
> hold until there were participants, and real use cases to meet.
>
> There were also recent cases where some new committers started to
> set up some default facilities which assumed a servlet environment
> and thereby broke the static docs build. We decided that the
> primary focus be static, yet enable project-specific dynamic.
one of the main goals of doco is to have 'zero codebase'... it's only a
plan, a vision, an architecture and a lot of configuration file. There
will be no *technical* overlap with the projects, doco is just a
project to "eat our dog food", shelving certain dreams in order to make
them come true.
It is true that forrest was started with that idea in mind, but later
turned out that people wanted to use it for their own stuff and it was
hard to keep goals in synch since a common denominator was needed.
instead of fighting to lock forrest down, I decided to step out and let
it grow.
Now, I'm back on the original dream that started in 1998: writing a
document management system (some people called it a "distributed word
processor") for our projects and use it as a testbase for further
research on the semantic web.
This *does not* overlap with any other project out there: no project is
focused on a single implementation and installation, but they are
focusing on writing reusable software.
SoC: Doco uses and glues pieces, the projects build the pieces and
receive back from Doco what they can incorporate in the general pieces.
This is my goal, but of course, I'm wide open to suggestions on how to
make things easier for everybody.
--
Stefano.
Re: Doco needs landing
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> David Crossley wrote:
>
> > Mmmm, i am not sure that i like this approach. "Doco" sounds
> > to me like one of the reasons that "Forrest" was started.
>
> that's right, but forrest took a different path and now focuses
> on static generation of web sites, full blown content management
> is not at reach there anymore.
That is a rash statement from afar.
Forrest was started by some visionaries with grand plans.
After a very short while, most of those people disappeared
and only a few committers remained to assist the fledgling.
Forrest documentation still talked about the grander plans.
Brilliant though it is, Forrest had to pull its horns in,
as it was not yet delivering on that vision.
So certain dreams had to be "shelved". Not abandoned, just put on
hold until there were participants, and real use cases to meet.
There were also recent cases where some new committers started to
set up some default facilities which assumed a servlet environment
and thereby broke the static docs build. We decided that the
primary focus be static, yet enable project-specific dynamic.
--David
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 28 Nov 2003, at 03:46, David Crossley wrote:
> Stefano Mazzocchi wrote:
>> Reinhard Poetz wrote:
>>
>>> ok, is there a way for others to help you or in other words:
>>> do you need some help?
>>
>> No, I move faster if I do stuff myself. There is no much code to
>> write,
>> just a lot of glue and finding out the pieces of the puzzle and
>> working
>> with somebody else is going to slow this down in prototypical phase.
>>
>> After the prototype is ready, there will be *tons* of polishing to do,
>> but I want to create the itches first, so that all of us can scratch
>> later.
>
> Mmmm, i am not sure that i like this approach. "Doco" sounds
> to me like one of the reasons that "Forrest" was started.
that's right, but forrest took a different path and now focuses on
static generation of web sites, full blown content management is not at
reach there anymore.
> What is worrying is that this one-person thing (though i trust
> Stefano to know what to do) will have no community to land in
> and Apache will spawn yet another new project.
> I don't mean to be cynical or anything, but Linotype and Portal
> landed in Cocoon as more-or-less functional things and not much
> has happened since.
wait a full second, David. I can't talk for Portal-oriented stuff since
I don't use it, but for linotype, it was ported to be IE5/mozilla
cross-platform, I received a few patches and Joerg is patching it to
fix jetty problems and there were discussions about integration with
cocoon forms and Lenya.
might not be "much", but it's something promising.
> I know that there is a trade-off between too much talk and not
> enough doing. However, without any discussion there is a risk
> that something fundamental will be missed.
I already did a full blown discussion on Doco. Everybody expressed a
warm +1 as several projects are involved: cocoon, forrest, lenya, james
and slide. Nobody complained about duplication of effort, rather the
opposite: everybody was happy to be used exactly for what it was
designed to do.
What to know what I'm doing right now? I'm debugging mount_webdav in
Darwin because there is a bug in their handling of webdav locks and I
can't mount a slide repository under mach-o. Yes, C code and recompile
part of my OS kernel, that's how bleeding-edge I'm getting.
If you think there is something wrong in the proposal, resurrect it and
complain. I'm all ears.
I told you I'm sick of politics and want to do stuff. I'm doing it. It
will be simply a proposal: it's easier to work alone that to make 5
different projects coordinating. If you disagree, you are more than
welcome to continue it the "community way". We'll see who comes out
with something that works faster.
After my proposal lands, you are welcome to tear it apart entirely. The
design is public, as the discussions that lead to it. If you have
technical suggestions, let's hear them. If you have community building
suggestions, well, I'll be happy to listen to them after the damn thing
will be saying "hello world".
In the meanwhile, as I said, don't wait for me.
--
Stefano.
Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Reinhard Poetz wrote:
>
> > ok, is there a way for others to help you or in other words:
> > do you need some help?
>
> No, I move faster if I do stuff myself. There is no much code to write,
> just a lot of glue and finding out the pieces of the puzzle and working
> with somebody else is going to slow this down in prototypical phase.
>
> After the prototype is ready, there will be *tons* of polishing to do,
> but I want to create the itches first, so that all of us can scratch
> later.
Mmmm, i am not sure that i like this approach. "Doco" sounds
to me like one of the reasons that "Forrest" was started.
What is worrying is that this one-person thing (though i trust
Stefano to know what to do) will have no community to land in
and Apache will spawn yet another new project.
I don't mean to be cynical or anything, but Linotype and Portal
landed in Cocoon as more-or-less functional things and not much
has happened since.
I know that there is a trade-off between too much talk and not
enough doing. However, without any discussion there is a risk
that something fundamental will be missed.
--David
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml index.xml
Posted by Stefano Mazzocchi <st...@apache.org>.
On 25 Nov 2003, at 17:09, Reinhard Poetz wrote:
> ok, is there a way for others to help you or in other words: do you
> need
> some help?
No, I move faster if I do stuff myself. There is no much code to write,
just a lot of glue and finding out the pieces of the puzzle and working
with somebody else is going to slow this down in prototypical phase.
After the prototype is ready, there will be *tons* of polishing to do,
but I want to create the itches first, so that all of us can scratch
later.
--
Stefano.
RE: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml index.xml
Posted by Reinhard Poetz <re...@apache.org>.
From: Stefano Mazzocchi
>
> On 24 Nov 2003, at 20:55, Reinhard Poetz wrote:
>
> >
> > From: gounis@osmosis.gr
> >
> >>
> >> so why not start to rate wiki pages so if anyone want to do
> >> something start with most wanted pages ?
> >
> > Good idea but I think it depends when Doco, our new documentation
> > system
> > will be available. AFAIK Stefano is working on it.
> >
> > Stefano WDYT?
>
> My suggestion is to keep doing stuff like Doco wasn't there.
Ok
> Don't
> depend on it as I don't have a timeline for this. I'm
> currently trying
> to get Slide operational and found myself in the middle of the
> resurrection of the slide community
nice to hear!
> and in the middle of apachecon.
>
> but I now have root access on moof.apache.org so I'll be able to make
> something available life pretty soon.
ok, is there a way for others to help you or in other words: do you need
some help?
(I'm not asking because I have too much time ATM but maybe somebody else
has ... :-)
--
Reinhard
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml index.xml
Posted by Stefano Mazzocchi <st...@apache.org>.
On 24 Nov 2003, at 20:55, Reinhard Poetz wrote:
>
> From: gounis@osmosis.gr
>
>>
>> so why not start to rate wiki pages so if anyone want to do
>> something
>> start with most wanted pages ?
>
> Good idea but I think it depends when Doco, our new documentation
> system
> will be available. AFAIK Stefano is working on it.
>
> Stefano WDYT?
My suggestion is to keep doing stuff like Doco wasn't there. Don't
depend on it as I don't have a timeline for this. I'm currently trying
to get Slide operational and found myself in the middle of the
resurrection of the slide community and in the middle of apachecon.
but I now have root access on moof.apache.org so I'll be able to make
something available life pretty soon.
But again, don't wait for me.
--
Stefano.
RE: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml index.xml
Posted by Reinhard Poetz <re...@apache.org>.
From: gounis@osmosis.gr
>
> so why not start to rate wiki pages so if anyone want to do
> something
> start with most wanted pages ?
Good idea but I think it depends when Doco, our new documentation system
will be available. AFAIK Stefano is working on it.
Stefano WDYT?
>
> -- stavros
>
>
> On Mon, 24 Nov 2003, Joerg Heinicke wrote:
>
> > On 24.11.2003 20:27, gounis@osmosis.gr wrote:
> >
> > > how is marked that a wiki page is ready to move to CVS?
> >
> > I guess almost every page has valuable content to be moved
> to the CVS.
> > The only question is: Who does the work? Reinhard simply
> started with
> > the maybe most wanted page for the official documentation.
Yep, it was my personal itch because I started with this page because
this is one of the FAQ
> If someone
> > else provides other pages we are glad to add it to the CVS.
Exactly
--
Reinhard
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml
book.xml index.xml
Posted by go...@osmosis.gr.
so why not start to rate wiki pages so if anyone want to do something
start with most wanted pages ?
-- stavros
On Mon, 24 Nov 2003, Joerg Heinicke wrote:
> On 24.11.2003 20:27, gounis@osmosis.gr wrote:
>
> > how is marked that a wiki page is ready to move to CVS?
>
> I guess almost every page has valuable content to be moved to the CVS.
> The only question is: Who does the work? Reinhard simply started with
> the maybe most wanted page for the official documentation. If someone
> else provides other pages we are glad to add it to the CVS.
>
> Joerg
>
>
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml
index.xml
Posted by Joerg Heinicke <jh...@virbus.de>.
On 24.11.2003 20:27, gounis@osmosis.gr wrote:
> how is marked that a wiki page is ready to move to CVS?
I guess almost every page has valuable content to be moved to the CVS.
The only question is: Who does the work? Reinhard simply started with
the maybe most wanted page for the official documentation. If someone
else provides other pages we are glad to add it to the CVS.
Joerg
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml
index.xml
Posted by Tony Collen <co...@umn.edu>.
gounis@osmosis.gr wrote:
> how is marked that a wiki page is ready to move to CVS?
I think whenever someone decides it's ready :)
>
>
> --stavros
Tony, soon to have time to devote to working on Cocoon again
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml
book.xml index.xml
Posted by go...@osmosis.gr.
how is marked that a wiki page is ready to move to CVS?
--stavros
On Mon, 24 Nov 2003, Joerg Heinicke wrote:
> On 24.11.2003 18:40, reinhard@apache.org wrote:
>
> > reinhard 2003/11/24 09:40:41
> >
> > Modified: src/documentation/xdocs book.xml index.xml
> > Added: src/documentation/xdocs features.xml
> > Log:
> > - add features list from http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
> > to CVS
>
> Cool. I guess it's the first content moved from Wiki to CVS.
>
> Joerg
>
>
Re: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml
index.xml
Posted by Upayavira <uv...@upaya.co.uk>.
Reinhard Poetz wrote:
>From: Joerg Heinicke
>
>
>
>>On 24.11.2003 18:40, reinhard@apache.org wrote:
>>
>>
>>
>>>reinhard 2003/11/24 09:40:41
>>>
>>> Modified: src/documentation/xdocs book.xml index.xml
>>> Added: src/documentation/xdocs features.xml
>>> Log:
>>> - add features list from
>>>
>>>
>>http://wiki.cocoondev.org/Wiki.jsp?> page=CocoonFeatures
>>
>>
>>>
>>>
>>>
>>to CVS
>>
>>Cool. I guess it's the
>>first content moved from Wiki to CVS.
>>
>>
>
>I think so too ;-)
>
>
'Fraid not. My CLI docs in CVS were transferred from the wiki ;-)
>It's time for Doco because moving content from Wiki to CVS is a very,
>very, very, very boring job. (Aren't there any tools which could help?)
>
>And it is very frustrating until you find out how all the things work
>until you can add docs to our documentation system.
>
>
I agree.
Regards, Upayavira
Re: Moving docs from Wiki
Posted by Upayavira <uv...@upaya.co.uk>.
Joerg Heinicke wrote:
> On 24.11.2003 21:55, Upayavira wrote:
>
>> Tony Collen wrote:
>>
>>> BTW, when a page is moved, I think we should keep the page on the
>>> wiki, and perhaps keep a record of when the last version was
>>> committed to CVS.
>>>
>>> Blowing away docs (like the features list) isn't too useful,
>>> especially since I was going to point to the version of the docs in
>>> the Wiki, and possibly make a bunch of revisions to the page. But
>>> then I suppose I could just edit the new file in CVS and commit.
>>
>>
>>
>> I agree that blowing away docs is bad. However, just leaving them is
>> pretty bad too.
>>
>> IMO, once a doc is moved to CVS, the original wiki page should be
>> replaced by a placeholder, which is where people can place comments
>> about the related page in CVS.
>
>
> From that point of view my solution must be really good in your
> opinion :-)
>
> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
Yup! Hadn't looked :-(
Regards, Upayavira
Re: Moving docs from Wiki
Posted by Tony Collen <co...@umn.edu>.
Bertrand Delacretaz wrote:
>
> Le Lundi, 24 nov 2003, à 22:00 Europe/Zurich, Joerg Heinicke a écrit :
>
>> ...From that point of view my solution must be really good in your
>> opinion :-)
>>
>> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
>
>
> hmmm..maybe we should push a little more towards patches?
>
> Instead of
> If you want to add further features or correct some issues please add it
> either here or provide a patch to the official documentation.
>
> I'd write
> You can still use this page for comments, but for content changes please
> provide patches as described in [MovedToCvs].
+1. I like the idea of having stuff gravitate more towards getting docs into CVS.. but sometimes I
just want to be able to flesh some stuff out on the Wiki. After enough revisions, I'd probably just
delete it and commit it myself, so we should just reccommend that patches be provided.
>
> WDYT?
>
Tony
Re: Moving docs from Wiki
Posted by Joerg Heinicke <jh...@virbus.de>.
On 24.11.2003 22:05, Bertrand Delacretaz wrote:
>
> Le Lundi, 24 nov 2003, à 22:00 Europe/Zurich, Joerg Heinicke a écrit :
>
>> ...From that point of view my solution must be really good in your
>> opinion :-)
>>
>> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
>
>
> hmmm..maybe we should push a little more towards patches?
>
> Instead of
> If you want to add further features or correct some issues please add it
> either here or provide a patch to the official documentation.
>
> I'd write
> You can still use this page for comments, but for content changes please
> provide patches as described in [MovedToCvs].
>
> WDYT?
No objection. Change it as you want to.
Joerg
Re: Moving docs from Wiki
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 24 nov 2003, à 22:00 Europe/Zurich, Joerg Heinicke a écrit :
> ...From that point of view my solution must be really good in your
> opinion :-)
>
> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
hmmm..maybe we should push a little more towards patches?
Instead of
If you want to add further features or correct some issues please add
it either here or provide a patch to the official documentation.
I'd write
You can still use this page for comments, but for content changes
please provide patches as described in [MovedToCvs].
WDYT?
Re: Moving docs from Wiki
Posted by Joerg Heinicke <jh...@virbus.de>.
On 24.11.2003 21:55, Upayavira wrote:
> Tony Collen wrote:
>
>> BTW, when a page is moved, I think we should keep the page on the
>> wiki, and perhaps keep a record of when the last version was committed
>> to CVS.
>>
>> Blowing away docs (like the features list) isn't too useful,
>> especially since I was going to point to the version of the docs in
>> the Wiki, and possibly make a bunch of revisions to the page. But
>> then I suppose I could just edit the new file in CVS and commit.
>
>
> I agree that blowing away docs is bad. However, just leaving them is
> pretty bad too.
>
> IMO, once a doc is moved to CVS, the original wiki page should be
> replaced by a placeholder, which is where people can place comments
> about the related page in CVS.
From that point of view my solution must be really good in your opinion :-)
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatures
Joerg
Re: Moving docs from Wiki
Posted by Joerg Heinicke <jh...@virbus.de>.
On 24.11.2003 21:58, Bertrand Delacretaz wrote:
>> ...I agree that blowing away docs is bad. However, just leaving them
>> is pretty bad too.
>>
>> IMO, once a doc is moved to CVS, the original wiki page should be
>> replaced by a placeholder, which is where people can place comments
>> about the related page in CVS.
>
>
> I have added a note about this at
> http://wiki.cocoondev.org/Wiki.jsp?page=MovedToCvs .
>
> Of course this can still be discussed here, but having the "rules" on
> the wiki should help.
>
> -Bertrand
Perfect, Bertrans :-)
Joerg
Re: Moving docs from Wiki
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 24 nov 2003, à 22:06 Europe/Zurich, Tony Collen a écrit :
> ...Would a centralized list of pages that were moved over (along with
> the last date they were moved) be useful to maintain?
If all moved pages point to
http://wiki.cocoondev.org/Wiki.jsp?page=MovedToCvs then the "Referenced
by" link of that page is your list ;-)
-Bertrand
Re: Moving docs from Wiki
Posted by Tony Collen <co...@umn.edu>.
Bertrand Delacretaz wrote:
> I have added a note about this at
> http://wiki.cocoondev.org/Wiki.jsp?page=MovedToCvs .
>
> Of course this can still be discussed here, but having the "rules" on
> the wiki should help.
I also put a note on the CocoonFeatures page about when it was last moved over to CVS, which is
useful. Would a centralized list of pages that were moved over (along with the last date they were
moved) be useful to maintain?
Or maybe that's too much to keep track of.
>
> -Bertrand
>
Tony
Re: Moving docs from Wiki
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 24 nov 2003, à 21:55 Europe/Zurich, Upayavira a écrit :
> ...I agree that blowing away docs is bad. However, just leaving them
> is pretty bad too.
>
> IMO, once a doc is moved to CVS, the original wiki page should be
> replaced by a placeholder, which is where people can place comments
> about the related page in CVS.
I have added a note about this at
http://wiki.cocoondev.org/Wiki.jsp?page=MovedToCvs .
Of course this can still be discussed here, but having the "rules" on
the wiki should help.
-Bertrand
Re: Moving docs from Wiki
Posted by Upayavira <uv...@upaya.co.uk>.
Tony Collen wrote:
> BTW, when a page is moved, I think we should keep the page on the
> wiki, and perhaps keep a record of when the last version was committed
> to CVS.
>
> Blowing away docs (like the features list) isn't too useful,
> especially since I was going to point to the version of the docs in
> the Wiki, and possibly make a bunch of revisions to the page. But
> then I suppose I could just edit the new file in CVS and commit.
I agree that blowing away docs is bad. However, just leaving them is
pretty bad too.
IMO, once a doc is moved to CVS, the original wiki page should be
replaced by a placeholder, which is where people can place comments
about the related page in CVS.
Regards, Upayavira
Re: Moving docs from Wiki
Posted by Upayavira <uv...@upaya.co.uk>.
Tony Collen wrote:
> Joerg Heinicke wrote:
>
>> The problem I saw (and because of this I removed the list) are the
>> missing diffs (or the bad usability with it) after further additions
>> to the page are made. Imagine in a half year you want to update the
>> page in the CVS, in the meantime there were 10 changes in the wiki
>> page, maybe someone reordered all the things! You can start from
>> scratch then or try to reproduce all the changes for the CVS version
>> - and this from version n to v. n+1, from v. n+1 to v. n+2 and so on.
>> After the removal of the list I think we have a cleaner approach.
>
>
> Hmm, then perhaps just a note of when the old docs were moved to CVS
> would suffice?
Exactly, and a reference to the new doc, and a space where people can
comment on the new doc. So only changes go on this wiki page.
Regards, Upayavira
Re: Moving docs from Wiki
Posted by Tony Collen <co...@umn.edu>.
Joerg Heinicke wrote:
> The problem I saw (and because of this I removed the list) are the
> missing diffs (or the bad usability with it) after further additions to
> the page are made. Imagine in a half year you want to update the page in
> the CVS, in the meantime there were 10 changes in the wiki page, maybe
> someone reordered all the things! You can start from scratch then or try
> to reproduce all the changes for the CVS version - and this from version
> n to v. n+1, from v. n+1 to v. n+2 and so on. After the removal of the
> list I think we have a cleaner approach.
Hmm, then perhaps just a note of when the old docs were moved to CVS would suffice?
>
> Joerg
>
Tony, can't think of a funny sig anymore.
Re: Moving docs from Wiki
Posted by Joerg Heinicke <jh...@virbus.de>.
On 24.11.2003 21:28, Tony Collen wrote:
> BTW, when a page is moved, I think we should keep the page on the wiki,
> and perhaps keep a record of when the last version was committed to CVS.
>
> Blowing away docs (like the features list) isn't too useful, especially
> since I was going to point to the version of the docs in the Wiki, and
> possibly make a bunch of revisions to the page. But then I suppose I
> could just edit the new file in CVS and commit.
The problem I saw (and because of this I removed the list) are the
missing diffs (or the bad usability with it) after further additions to
the page are made. Imagine in a half year you want to update the page in
the CVS, in the meantime there were 10 changes in the wiki page, maybe
someone reordered all the things! You can start from scratch then or try
to reproduce all the changes for the CVS version - and this from version
n to v. n+1, from v. n+1 to v. n+2 and so on. After the removal of the
list I think we have a cleaner approach.
Joerg
Re: Moving docs from Wiki
Posted by Tony Collen <co...@umn.edu>.
BTW, when a page is moved, I think we should keep the page on the wiki, and perhaps keep a record of
when the last version was committed to CVS.
Blowing away docs (like the features list) isn't too useful, especially since I was going to point
to the version of the docs in the Wiki, and possibly make a bunch of revisions to the page. But
then I suppose I could just edit the new file in CVS and commit.
Tony
RE: Moving docs from Wiki
Posted by go...@osmosis.gr.
On Wed, 26 Nov 2003, Reinhard Poetz wrote:
>
> From: David Crossley
>
> > Vadim Gritsenko wrote:
> > > Reinhard Poetz wrote:
> > >
> > > >No problem, that was not the difficult part - I had more problems
> > > >with the publishing process itself:
> >
> > I presume that you know about
> > http://wiki.cocoondev.org/Wiki.jsp?page=CocoonWebsiteUpdate
> >
> > Agreed, the process could be easier. Thank your lucky stars
> > that you were not struggling with Cocoon docs a couple of years ago.
> >
> > > > 1) complete build of Cocoon including documentation
> > > > 2) use forrest to generate 'real' documentation
> > >
> > > "build docs" does these two items.
> > >
> > > > 3) then I used 'forrest run' and and XML editor to edit/create
> > > > my docs (it took me very long until I found out *where* I
> > > > can edit my docs)
> >
> > Sorry. The cvs head version of Forrest is leaving source and
> > skins in-place and not copying them around. (But Cocoon is
> > using 0.5 ATM.)
> >
> > > > BTW: an XML editor is the *worst* thing to edit
> > content at all
> > > > ...
> >
> > Why do you say that? We should fix it then.
>
> The only fix which will help me is a WYSIWIG-editor - otherwise it is
> always painful to edit content.
altova's authentic can provide a WYSIWIG but every time i had to try to
setup an XML/XSL/SPS (SPS is a autheintic xml file that "drive" the
WYSISWG) i have no reluts.
maybe a authentic view of xdocs can help
-- stavros
>
> >
> > > > 4) then I had to copy the changed docs *manually* back into
> > > > the Cocoon docs to check them in
> >
> > Yes, see answer to 3). In Forrest-0.5 there is the 'forrest
> > backcopy' target for that.
> >
> > > > 5) then I had to generate the 'site' and copy them *manually*
> > > > into cocoon-site
> > >
> > > "build docs" does (5) too.
> > >
> > > > 6) then I checked in cocoon-2.1
> > > > 7) then I checked in cocoon-site
> >
> > Cannot be avoided.
> >
> > > > 8) then I updated our website using the CVS client on
> > > > cvs.apache.org
> > >
> > > Yes, these are manual steps.
> >
> > Some projects have a cron job to do that automatically,
> > say every 12 hours.
>
>
> thanks for your explanations - I'll look them up when I add/change some
> docs in the future!
>
> --
> Reinhard
>
>
RE: Moving docs from Wiki
Posted by Reinhard Poetz <re...@apache.org>.
From: David Crossley
> Vadim Gritsenko wrote:
> > Reinhard Poetz wrote:
> >
> > >No problem, that was not the difficult part - I had more problems
> > >with the publishing process itself:
>
> I presume that you know about
> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonWebsiteUpdate
>
> Agreed, the process could be easier. Thank your lucky stars
> that you were not struggling with Cocoon docs a couple of years ago.
>
> > > 1) complete build of Cocoon including documentation
> > > 2) use forrest to generate 'real' documentation
> >
> > "build docs" does these two items.
> >
> > > 3) then I used 'forrest run' and and XML editor to edit/create
> > > my docs (it took me very long until I found out *where* I
> > > can edit my docs)
>
> Sorry. The cvs head version of Forrest is leaving source and
> skins in-place and not copying them around. (But Cocoon is
> using 0.5 ATM.)
>
> > > BTW: an XML editor is the *worst* thing to edit
> content at all
> > > ...
>
> Why do you say that? We should fix it then.
The only fix which will help me is a WYSIWIG-editor - otherwise it is
always painful to edit content.
>
> > > 4) then I had to copy the changed docs *manually* back into
> > > the Cocoon docs to check them in
>
> Yes, see answer to 3). In Forrest-0.5 there is the 'forrest
> backcopy' target for that.
>
> > > 5) then I had to generate the 'site' and copy them *manually*
> > > into cocoon-site
> >
> > "build docs" does (5) too.
> >
> > > 6) then I checked in cocoon-2.1
> > > 7) then I checked in cocoon-site
>
> Cannot be avoided.
>
> > > 8) then I updated our website using the CVS client on
> > > cvs.apache.org
> >
> > Yes, these are manual steps.
>
> Some projects have a cron job to do that automatically,
> say every 12 hours.
thanks for your explanations - I'll look them up when I add/change some
docs in the future!
--
Reinhard
Re: Moving docs from Wiki
Posted by David Crossley <cr...@indexgeo.com.au>.
Vadim Gritsenko wrote:
> Reinhard Poetz wrote:
>
> >No problem, that was not the difficult part - I had more problems with
> >the publishing process itself:
I presume that you know about
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonWebsiteUpdate
Agreed, the process could be easier. Thank your lucky stars that
you were not struggling with Cocoon docs a couple of years ago.
> > 1) complete build of Cocoon including documentation
> > 2) use forrest to generate 'real' documentation
>
> "build docs" does these two items.
>
> > 3) then I used 'forrest run' and and XML editor to edit/create
> > my docs (it took me very long until I found out *where* I
> > can edit my docs)
Sorry. The cvs head version of Forrest is leaving source and skins
in-place and not copying them around. (But Cocoon is using 0.5 ATM.)
> > BTW: an XML editor is the *worst* thing to edit content at all ...
Why do you say that? We should fix it then.
> > 4) then I had to copy the changed docs *manually* back into
> > the Cocoon docs to check them in
Yes, see answer to 3). In Forrest-0.5 there is the 'forrest backcopy'
target for that.
> > 5) then I had to generate the 'site' and copy them *manually*
> > into cocoon-site
>
> "build docs" does (5) too.
>
> > 6) then I checked in cocoon-2.1
> > 7) then I checked in cocoon-site
Cannot be avoided.
> > 8) then I updated our website using the CVS client on cvs.apache.org
>
> Yes, these are manual steps.
Some projects have a cron job to do that automatically,
say every 12 hours.
--David
Re: Moving docs from Wiki
Posted by Vadim Gritsenko <va...@verizon.net>.
Reinhard Poetz wrote:
...
>No problem, that was not the difficult part - I had more problems with
>the publishing process itself:
>
> 1) complete build of Cocoon including documentation
> 2) use forrest to generate 'real' documentation
>
>
"build docs" does these two items.
> 3) then I used 'forrest run' and and XML editor to edit/create
> my docs (it took me very long until I found out *where* I
> can edit my docs)
> BTW: an XML editor is the *worst* thing to edit content at all ...
> 4) then I had to copy the changed docs *manually* back into
> the Cocoon docs to check them in
> 5) then I had to generate the 'site' and copy them *manually*
> into cocoon-site
>
>
"build docs" does (5) too.
> 6) then I checked in cocoon-2.1
> 7) then I checked in cocoon-site
> 8) then I updated our website using the CVS client on cvs.apache.org
>
>
Yes, these are manual steps.
Vadim
RE: Moving docs from Wiki
Posted by Reinhard Poetz <re...@apache.org>.
From: David Crossley
> Tony Collen wrote:
> > Bertrand Delacretaz wrote:
> > > Reinhard Poetz a écrit :
> > >
> > >> ..It's time for Doco because moving content from Wiki to
> CVS is a
> > >> very, very, very, very boring job. (Aren't there any tools which
> > >> could help?)...
> > >
> > > If you're talking about format conversion, JSPWiki's HTML
> shouldn't
> > > be
> > > hard to convert to xdocs via XSLT. It uses skins so it is
> also possible
> > > to add more structure to the HTML to make this easier.
> >
> > Or we get Chaperon to parse the Wiki files themselves. This seems
> > simpler.
>
> There is this excellent project called Apache Forrest.
> See the demo of 'forrest seed site' at
> http://forrestbot.cocoondev.org/sites/x> ml-forrest-template/
>
> and look for the Wiki Sample which
> employs Chaperon.
>
> I am very sorry Reinhard, i should have recalled that ability
> when you talked about moving the Features doc.
No problem, that was not the difficult part - I had more problems with
the publishing process itself:
1) complete build of Cocoon including documentation
2) use forrest to generate 'real' documentation
3) then I used 'forrest run' and and XML editor to edit/create
my docs (it took me very long until I found out *where* I
can edit my docs)
BTW: an XML editor is the *worst* thing to edit content at all ...
4) then I had to copy the changed docs *manually* back into
the Cocoon docs to check them in
5) then I had to generate the 'site' and copy them *manually*
into cocoon-site
(... I forgot to copy some of the docs - thanks to Jörg who
reminded me that a change in the menu structure has
impact on many docs)
6) then I checked in cocoon-2.1
7) then I checked in cocoon-site
8) then I updated our website using the CVS client on cvs.apache.org
As I had never done this before it took me a while to figure out how all
those things work together. Sorry, that's no fun. If the features docs
hadn't been so important for me because I think this was *the* big
missing thing in our docs I would have given up after an hour. As I
already said three times in my mails yesterday I'm really looking
forward to using Doco - this will give the Cocoon documentation a great
push forward!!!
Cheers,
Reinhard
Re: Moving docs from Wiki
Posted by David Crossley <cr...@indexgeo.com.au>.
Tony Collen wrote:
> Bertrand Delacretaz wrote:
> > Reinhard Poetz a écrit :
> >
> >> ..It's time for Doco because moving content from Wiki to CVS is a very,
> >> very, very, very boring job. (Aren't there any tools which could
> >> help?)...
> >
> > If you're talking about format conversion, JSPWiki's HTML shouldn't be
> > hard to convert to xdocs via XSLT. It uses skins so it is also possible
> > to add more structure to the HTML to make this easier.
>
> Or we get Chaperon to parse the Wiki files themselves. This seems simpler.
There is this excellent project called Apache Forrest.
See the demo of 'forrest seed site' at
http://forrestbot.cocoondev.org/sites/xml-forrest-template/
and look for the Wiki Sample which employs Chaperon.
I am very sorry Reinhard, i should have recalled that ability when
you talked about moving the Features doc.
--David
Re: Moving docs from Wiki (was : cvs commit: cocoon-2.1/src/documentation/xdocs
features.xml ...)
Posted by Tony Collen <co...@umn.edu>.
Bertrand Delacretaz wrote:
> Le Lundi, 24 nov 2003, à 19:22 Europe/Zurich, Reinhard Poetz a écrit :
>
>> ..It's time for Doco because moving content from Wiki to CVS is a very,
>> very, very, very boring job. (Aren't there any tools which could
>> help?)...
>
>
> If you're talking about format conversion, JSPWiki's HTML shouldn't be
> hard to convert to xdocs via XSLT. It uses skins so it is also possible
> to add more structure to the HTML to make this easier.
Or we get Chaperon to parse the Wiki files themselves. This seems simpler.
>
>
> - Bertrand, who likes these funny new sigs but is afraid he won't have
> much time for Cocoon in the next few weeks
>
Tony, who will have a hard time coming up with a new sig every time he writes to the lists.
Moving docs from Wiki (was : cvs commit: cocoon-2.1/src/documentation/xdocs features.xml ...)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 24 nov 2003, à 19:22 Europe/Zurich, Reinhard Poetz a écrit :
> ..It's time for Doco because moving content from Wiki to CVS is a very,
> very, very, very boring job. (Aren't there any tools which could
> help?)...
If you're talking about format conversion, JSPWiki's HTML shouldn't be
hard to convert to xdocs via XSLT. It uses skins so it is also possible
to add more structure to the HTML to make this easier.
- Bertrand, who likes these funny new sigs but is afraid he won't have
much time for Cocoon in the next few weeks
RE: cvs commit: cocoon-2.1/src/documentation/xdocs features.xml book.xml index.xml
Posted by Reinhard Poetz <re...@apache.org>.
From: Joerg Heinicke
> On 24.11.2003 18:40, reinhard@apache.org wrote:
>
> > reinhard 2003/11/24 09:40:41
> >
> > Modified: src/documentation/xdocs book.xml index.xml
> > Added: src/documentation/xdocs features.xml
> > Log:
> > - add features list from
> http://wiki.cocoondev.org/Wiki.jsp?> page=CocoonFeatures
> >
> to CVS
>
> Cool. I guess it's the
> first content moved from Wiki to CVS.
I think so too ;-)
It's time for Doco because moving content from Wiki to CVS is a very,
very, very, very boring job. (Aren't there any tools which could help?)
And it is very frustrating until you find out how all the things work
until you can add docs to our documentation system.
--
Reinhard