You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@gmx.net> on 2003/03/11 08:32:06 UTC
Snapshot links at Cocoon website
> From: Pier Fumagalli [mailto:pier@betaversion.org]
>
> On 10/3/03 7:42, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
>
> > b) Let's get the nightly build working asap
>
> Carsten, are you talking about the nightly builds (GUMP) or
> the nightly CVS snapshots???
>
> Because if the latter, I was just waiting for the CVS
> repository split to integrate their automatic checkout back
> into the snapshotting scripts already ran by "root" on
> cvs.apache.org...
>
> And I've done that (well, just now, but at least one less
> problem to worry
> about)
>
> http://cvs.apache.org/snapshots/cocoon-2.0/
> http://cvs.apache.org/snapshots/cocoon-2.1/
>
> I also patched the "download" (mirror) page to reflect the change...
>
> http://xml.apache.org/cocoon/mirror.cgi#nightly
Currently the link "Dev Snapshots" leads to
http://xml.apache.org/from-cvs/xml-cocoon2/. Maybe that's the reason why
it can't be found by many people.
I suggest linking to http://xml.apache.org/cocoon/mirror.cgi#nightly but
I guess that's your intention ;-)
Regards,
Reinhard
Re: Snapshot links at Cocoon website
Posted by Jeff Turner <je...@apache.org>.
On Tue, Mar 11, 2003 at 07:31:10AM -0500, Diana Shannon wrote:
<snip/>
> 3. I was really excited about Forrest transition, thinking the
> automation would save me all of the above time which I could devote to
> docs content. Unfortunately:
> - only a few committers participated in the trial run, so it seemed to
> me, interest/support is not that great.
> - Forresters seemed to suggest, and I could be wrong, that the live site
> cvs update would **still** be required even with Forrest. Thus, I failed
> to see how the transition would make my volunteer committer life any
> more liberated, since this time killing step was still necessary.
Last time this came up, I don't think the Forrestbot was fully
operational. For many websites (xml-site, forrest, fop, avalon), the
update/commit process is now automated (still human-triggered though).
API docs are (IMHO) outside Forrest's concern. I think they should be
updated separately to the main site -- Javadocs are *big* and committing
them all for trivial updates will quickly full up icarus disk space.
--Jeff
>
> Diana
>
Re: esql samples
Posted by Torsten Curdt <tc...@dff.st>.
Geoff Howard wrote:
>
>>
>>> For now, though for purposes of reviving the samples quickly it may
>>> be as easy as re-commiting a new db.script into the database block
>>> with the changes in it.
>>> IIUC hsql uses this file as its persistent store of data - when you
>>> shut down, it gets overwritten with what is in memory. So, if you
>>> make changes to the file,
>>> then restart cocoon to reload the changes, they disappear. It was
>>> awkward for me trying to contribute (read: I lost changes a few times
>>> and am still getting over it emotionally ;) ) but that's not
>>> happening much.
>>
>>
>> ...and I assume it's get loaded when it comes up. So all we
>> need to do is to put a file into the webapp (at the right place)
>> so it gets loaded as it where shut down before, right?
>
> That was my experience.
cool - so I'll fix it that way
--
Torsten
Re: esql samples
Posted by Geoff Howard <co...@leverageweb.com>.
>
>>For now, though for purposes of reviving the samples quickly it may be as
>>easy as re-commiting a new db.script into the database block with the
>>changes in it.
>>IIUC hsql uses this file as its persistent store of data - when you shut
>>down, it gets overwritten with what is in memory. So, if you make
>>changes to the file,
>>then restart cocoon to reload the changes, they disappear. It was
>>awkward for me trying to contribute (read: I lost changes a few times and
>>am still getting over it emotionally ;) ) but that's not happening much.
>
>...and I assume it's get loaded when it comes up. So all we
>need to do is to put a file into the webapp (at the right place)
>so it gets loaded as it where shut down before, right?
That was my experience.
Geoff
Re: esql samples
Posted by Torsten Curdt <tc...@dff.st>.
>> Hm... I see. So it's enough to just copy the sql script into the
>> WEB-INF/db location. I'll take look...
>>
>>> I was just getting ready to see if there is an ant call to process a
>>> sql script over jdbc (I'm sure there is, just don't know ant well
>>> enough) but I'd make slow progress now as I'm very time limited.
>>
>>
>> Well, but when do you wanna call the target?
>> The hsqldb would need to be running.
>
>
> Doh! Well, it could be a stand-alone target with a note on the
> database samples page that it should be run while cocoon is up.
>
> HSQL can be run separately from cocoon, of course and could be started up
> from the build (with a custom task?).
aaaah... no
> For now, though for purposes of reviving the samples quickly it may be
> as easy as re-commiting a new db.script into the database block with the
> changes in it.
>
> IIUC hsql uses this file as its persistent store of data - when you shut
> down, it gets overwritten with what is in memory. So, if you make
> changes to the file,
> then restart cocoon to reload the changes, they disappear. It was
> awkward for me trying to contribute (read: I lost changes a few times
> and am still getting over it emotionally ;) ) but that's not happening
> much.
...and I assume it's get loaded when it comes up. So all we
need to do is to put a file into the webapp (at the right place)
so it gets loaded as it where shut down before, right?
<snip/>
>> But since this is only used for the "personal" datasource it doesn't
>> make any sense all to have it configurable in the properties. It's just
>> for the example database. Let's KISS :)
>>
>> So if noone is really keen on those properties I'll remove them from the
>> build. No need to filter then.
>
>
> Christian's got another thread on this. Seems fine to me, for
> what that's worth.
excellent
--
Torsten
Re: esql samples
Posted by Geoff Howard <co...@leverageweb.com>.
At 12:33 PM 3/11/2003, you wrote:
>>>I wanted to look after the esql samples but found
>>>
>>>1) the hsqldb not being filled (where did we do this before?)
>>
>>I noticed this a few days ago, but haven't had time to write about it.
>>I'm pretty sure from experiencing adding a new table to the demo a month
>>ago that the hsqldb was not built automatically. I had to modify the
>>hsql running on my machine, and commit WEB-INF/db/hsql.script (or
>>whatever) that was created when hsql shut down. I could be wrong. But
>>that's what I remember.
>
>Hm... I see. So it's enough to just copy the sql script into the
>WEB-INF/db location. I'll take look...
>
>>I was just getting ready to see if there is an ant call to process a sql
>>script over jdbc (I'm sure there is, just don't know ant well enough) but
>>I'd make slow progress now as I'm very time limited.
>
>Well, but when do you wanna call the target?
>The hsqldb would need to be running.
Doh! Well, it could be a stand-alone target with a note on the
database samples page that it should be run while cocoon is up.
HSQL can be run separately from cocoon, of course and could be started up
from the build (with a custom task?).
For now, though for purposes of reviving the samples quickly it may be as
easy as re-commiting a new db.script into the database block with the
changes in it.
IIUC hsql uses this file as its persistent store of data - when you shut
down, it gets overwritten with what is in memory. So, if you make changes
to the file,
then restart cocoon to reload the changes, they disappear. It was awkward
for me trying to contribute (read: I lost changes a few times and am still
getting over it emotionally ;) ) but that's not happening much.
>I think the copy into the db directory should do it.
>
>>>2) the jdbc url, user and password not being replaced
>>
>>This i'm not sure about, but was it done by filter before?
>
>Yes it was. And the variables are already in the properties.
>As well the build.xml looks like it *should* work (on the first glance).
>
>But since this is only used for the "personal" datasource it doesn't
>make any sense all to have it configurable in the properties. It's just
>for the example database. Let's KISS :)
>
>So if noone is really keen on those properties I'll remove them from the
>build. No need to filter then.
Christian's got another thread on this. Seems fine to me, for
what that's worth.
Geoff
>--
>Torsten
>
>
xmlforms schematron + abstract rules
Posted by Jeroen Cranendonk <j....@emaxx.nl>.
Hello all :)
I've got a problem, first the context :
Xmlforms uses schematrons to validate forms, if I'm not mistaken the
parsing/applying of schematron xml files is done in the xmlforms java code.
It seems that schematron 'abstract rules' as specified for example in:
http://www.zvon.org/ZvonSW/ZvonSchematron/Reference/Output/extends.html
are not implemented yet.
The problem is my company wants to use abstract rules in schematrons in
xmlforms, and they told me to go and implement it. I'm quite new still to
cocoon, xmlforms, and schematrons. And I doubt if I'll be able to do a very
clean, proper or good implementation. But I might give it a try :)
Before I start tho, is anyone already planning to implement this?, is there
anything to look out for while doing this?, is there a good reason this isn't
implemented yet?, are there any hints anyone would like to give ? :)
I'd be very gratefull for any answers anyone would like to share,
many thanks in advance and greetings,
Jeroen Cranendonk.
Re: esql samples
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
>>But what would be the benefit instead of just appending it?
>
>
> We are save from file format changes of HSQLDB. For example, the
> format from version 1.6 is different from version 1.7 You didn't
> notice because I converted the file back then ;-)
Aaahhh... ok!
Sure then let's use the hsqldb script tool :)
--
Torsten
Re: esql samples
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 13.Mar.2003 -- 02:44 PM, Torsten Curdt wrote:
> <snip/>
>
> >That was not my understanding from Chris's email. By "has to happen at
> >runtime" do you mean because of the nature of the hsql call, or some
> >other logical constraint? I understood him to mean that the call would
> >cause hsql to parse and run that script at build time, and shut
> >immediately down. I would assume it would skip the overhead of setting
> >up listeners, etc. and thus be pretty efficient.
>
> Uh... did understand it differently in the first place.
> Thought it connects more or less via JDBC.
>
> Chris could you clarify?
HSQLDB know different operation modes (4, actually). One is acting as
server, one is a library mode where it is client and server at the
same time. The operation mode is determined through the URL. Database
files are identical for all modes.
My suggestion was to run the library mode from ant.
> But what would be the benefit instead of just appending it?
We are save from file format changes of HSQLDB. For example, the
format from version 1.6 is different from version 1.7 You didn't
notice because I converted the file back then ;-)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: esql samples
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> That was not my understanding from Chris's email. By "has to happen at
> runtime" do you mean because of the nature of the hsql call, or some
> other logical constraint? I understood him to mean that the call would
> cause hsql to parse and run that script at build time, and shut
> immediately down. I would assume it would skip the overhead of setting
> up listeners, etc. and thus be pretty efficient.
Uh... did understand it differently in the first place.
Thought it connects more or less via JDBC.
Chris could you clarify?
But what would be the benefit instead of just appending it?
--
Torsten
Re: esql samples
Posted by Geoff Howard <co...@leverageweb.com>.
At 08:28 AM 3/13/2003, Torsten wrote:
><snip/>
>
>>It seems wrong to put it in the hsql block (because it's specific to the
>>db samples). So I guess in the db block. That makes the hsql block
>>build (presuming that's where the hsql script call goes) depend on the
>>database block, which is fine as you point out.
>
>Agreed - but I am really not in favor of the hsql script call.
>This call has to happen at runtime not build time :-/
That was not my understanding from Chris's email. By "has to happen at
runtime" do you mean because of the nature of the hsql call, or some other
logical constraint? I understood him to mean that the call would cause
hsql to parse and run that script at build time, and shut immediately
down. I would assume it would skip the overhead of setting up listeners,
etc. and thus be pretty efficient.
Geoff
Re: esql samples
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> It seems wrong to put it in the hsql block (because it's specific to the
> db samples). So I guess in the db block. That makes the hsql block
> build (presuming that's where the hsql script call goes) depend on the
> database block, which is fine as you point out.
Agreed - but I am really not in favor of the hsql script call.
This call has to happen at runtime not build time :-/
> Am I right that "block"
> dependencies are not dealt with yet, since we don't really have blocks
> but sub-builds called "blocks"?
AFAIK - yes
So I propose just to split the cocoodb.script into a standard
sql and a hsqldb specific init script. Then let ant merge them
and put them into WEB-INF/db whenever the database block is included.
I don't think it's too bad to have the database block copy that
tiny sql file into WEB-INF/db even if no hsqldb is installed.
We can solve this later with the block dependencies...
We could link to a documentation page from the samples where we
describe how to setup the database examples to work with other
datebases. Then we don't have the hassle with the sql compatibility
and the users should also be fine.
--
Torsten
Re: esql samples
Posted by Geoff Howard <co...@leverageweb.com>.
At 03:44 AM 3/13/2003, Christian wrote:
>On 12.Mar.2003 -- 01:58 PM, Geoff Howard wrote:
> > At 11:23 AM 3/12/2003, Torsten wrote:
> > ><snip/>
> > >
> > >>>But the .script file *is* actually a simple .sql script.
> > >>Yes, but as I remember it, wouldn't be appropriate to use as the
> > >>source in other DB's, but...
>
>I think the main point is that we should have a clean SQL file that
>contains only the necessary statements to create the schema (all
>tables) and fills them with test data. The db.script has the
>disadvantages that it contains hsqldb specific internal aspects (it
>will even log connections!). Ideally, such a file would contain some
>comments as well, helping to understand the hsqldb specific syntax
>e.g. types, constraints, and autoincrements.
>
>However, another possibility is to call org.hsqldb.util.ScriptTool
>from ant and connect to a hsqldb file: This would use a JDBC URL like
>jdbc:hsqldb:path/to/database/file like:
>
> <java classname="org.hsqldb.util.ScriptTool">
> <arg value="-url jdbc:hsqldb: -database path/to/database/file
> -batch -script script.sql"/>
> <classpath>
> <pathelement location="hsqldb.jar"/>
> </classpath>
> </java>
Yes, this is exactly what I was hoping existed with hsql. Hopefully it
doesn't take very long to run...
<snip/>
> > BTW - there would need to be some logic to determine during the database
> > build whether the hsql block was installed (and it would need to have been
> > processed first, right?) before attempting to merge this script with a
> file
> > created by the hsql block. Or am I missing something?
>
>Well, I don't see anyone use the embedded hsqldb used for anything
>else than the samples, so, why not put it into the hsqldb block. Don't
>get me wrong, I really like hsqldb, it's cool, small, fast and has
>some nice features. It does have its uses. It's just that I wouldn't
>want to start, stop my database server together with Cocoon in a real
>setup. That would render the approach of a database ridiculous.
That's probably true. Where then does script.sql (as referred to in the
ant snippet above) go?
It seems wrong to put it in the hsql block (because it's specific to the db
samples). So I guess in the db block. That makes the hsql block build
(presuming that's where the hsql script call goes) depend on the database
block, which is fine as you point out. Am I right that "block"
dependencies are not dealt with yet, since we don't really have blocks but
sub-builds called "blocks"?
Geoff
> Chris.
>--
>C h r i s t i a n H a u l
>haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: esql samples
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 12.Mar.2003 -- 01:58 PM, Geoff Howard wrote:
> At 11:23 AM 3/12/2003, Torsten wrote:
> ><snip/>
> >
> >>>But the .script file *is* actually a simple .sql script.
> >>Yes, but as I remember it, wouldn't be appropriate to use as the
> >>source in other DB's, but...
I think the main point is that we should have a clean SQL file that
contains only the necessary statements to create the schema (all
tables) and fills them with test data. The db.script has the
disadvantages that it contains hsqldb specific internal aspects (it
will even log connections!). Ideally, such a file would contain some
comments as well, helping to understand the hsqldb specific syntax
e.g. types, constraints, and autoincrements.
However, another possibility is to call org.hsqldb.util.ScriptTool
from ant and connect to a hsqldb file: This would use a JDBC URL like
jdbc:hsqldb:path/to/database/file like:
<java classname="org.hsqldb.util.ScriptTool">
<arg value="-url jdbc:hsqldb: -database path/to/database/file -batch -script script.sql"/>
<classpath>
<pathelement location="hsqldb.jar"/>
</classpath>
</java>
Thus we have
+ clean separation of schema / data from hsqldb internal data
+ automatic initialization without much trouble
> >>The only reason approaches like this would have any value would be to
> >>facilitate using other than hsql db for the samples. If I already have
> >>mysql installed, I may
> >>choose to exclude the hsql block.
> >
> >Don't understand this. Why would you want to try the samples in your db?
> >I don't really see why we should take the burden on making sure that our
> >sql creates all tables and data successfully on database X just because
> >the user wants to run the samples on his database out of the box.
Absolutely.
> >(I mean it's very basic sql - it should not. But I wouldn't take a bet on
> >any datatype or the primary key definitions. I've seen too much crap out
> >there;)
:-)
> >Don't take me wrong. I am not against this - but atleast *I* just cannot
> >see the real value yet. Please tell me :)
>
> It's OK, I don't even know if I'm for it! ;) Seriously, I guess Chris has
> echoed that it has been a frequent request, and it seems reasonable to
> me. But admittedly that's not a very compelling case for a lot of work. I
> see two separate questions:
>
> 1) Should we take steps to make it easier to run the samples in another
> database.
> 2) Should we automate it.
>
> I'd say the first is worth some effort, and the second probably not if they
> can be separated.
>
> So, if we have a samples.sql that gets merged into db.script via ant for
> the database block using hsql by default and can also be used to manually
> create the appropriate tables and sample data in your db of choice, that
> would accomplish #1 while stopping short of #2.
>
> Does that KISS?
>
> BTW - there would need to be some logic to determine during the database
> build whether the hsql block was installed (and it would need to have been
> processed first, right?) before attempting to merge this script with a file
> created by the hsql block. Or am I missing something?
Well, I don't see anyone use the embedded hsqldb used for anything
else than the samples, so, why not put it into the hsqldb block. Don't
get me wrong, I really like hsqldb, it's cool, small, fast and has
some nice features. It does have its uses. It's just that I wouldn't
want to start, stop my database server together with Cocoon in a real
setup. That would render the approach of a database ridiculous.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: esql samples
Posted by Geoff Howard <co...@leverageweb.com>.
At 11:23 AM 3/12/2003, Torsten wrote:
><snip/>
>
>>>But the .script file *is* actually a simple .sql script.
>>Yes, but as I remember it, wouldn't be appropriate to use as the
>>source in other DB's, but...
>
>Can you remember why? I haven't really looked closer into it.
Well, it was the stuff like:
GRANT ALL ON CLASS "org.hsqldb.Library" TO PUBLIC
GRANT ALL ON CLASS "java.lang.Math" TO PUBLIC
CREATE USER SA PASSWORD "" ADMIN
CREATE ALIAS DAYNAME FOR "org.hsqldb.Library.dayname"
CREATE ALIAS SPACE FOR "org.hsqldb.Library.space"
CREATE ALIAS SUBSTRING FOR "org.hsqldb.Library.substring"
CREATE ALIAS SQRT FOR "java.lang.Math.sqrt"
CREATE ALIAS ABS FOR "java.lang.Math.abs"
...
That I wouldn't want running in my db. However, looking back at your
original suggestion about merging the base hsql with the samples, there may
not be a problem. We could use just:
CREATE TABLE DEPARTMENT(ID INTEGER NOT NULL,NAME VARCHAR NOT NULL,UNIQUE(ID))
CREATE TABLE EMPLOYEE(ID INTEGER NOT NULL,DEPARTMENT_ID INTEGER NOT
NULL,NAME VARCHAR NOT NULL,UNIQUE(ID))
CREATE TABLE USER(UID INTEGER IDENTITY PRIMARY KEY,NAME VARCHAR,FIRSTNAME
VARCHAR,UNAME VARCHAR,UNIQUE(UNAME))
CREATE TABLE GROUPS(GID INTEGER IDENTITY PRIMARY KEY,GNAME
VARCHAR,UNIQUE(GNAME))
CREATE TABLE USER_GROUPS(UID INTEGER,GID INTEGER,UNIQUE(UID,GID),FOREIGN
KEY(UID)REFERENCES USER(UID),FOREIGN KEY(GID)REFERENCES GROUPS(GID))
CREATE TABLE STATE_TAX(CATEGORY VARCHAR NOT NULL,GROSSTAX_COLLECTED DOUBLE
NOT NULL,NETTAX_COLLECTED DOUBLE NOT NULL,YEAR INTEGER NOT NULL)
CREATE TABLE MEDIA(ID INTEGER IDENTITY PRIMARY KEY,IMAGE BINARY,MIMETYPE
VARCHAR)
INSERT INTO DEPARTMENT VALUES(1,'Development')
INSERT INTO DEPARTMENT VALUES(2,'Management')
INSERT INTO DEPARTMENT VALUES(3,'Testers')
INSERT INTO EMPLOYEE VALUES(1,1,'Donald Ball')
INSERT INTO EMPLOYEE VALUES(2,1,'Sylvain Wallez ')
INSERT INTO EMPLOYEE VALUES(3,1,'Carsten Ziegeler ')
...
The only question it seem to me being, does hsql honor vanilla sql _here_,
or do things have to be created in some subset/flavor specific to hsql?
>>The only reason approaches like this would have any value would be to
>>facilitate using other than hsql db for the samples. If I already have
>>mysql installed, I may
>>choose to exclude the hsql block.
>
>Don't understand this. Why would you want to try the samples in your db?
>I don't really see why we should take the burden on making sure that our
>sql creates all tables and data successfully on database X just because
>the user wants to run the samples on his database out of the box.
>(I mean it's very basic sql - it should not. But I wouldn't take a bet on
>any datatype or the primary key definitions. I've seen too much crap out
>there;)
>
>Don't take me wrong. I am not against this - but atleast *I* just cannot
>see the real value yet. Please tell me :)
It's OK, I don't even know if I'm for it! ;) Seriously, I guess Chris has
echoed that it has been a frequent request, and it seems reasonable to
me. But admittedly that's not a very compelling case for a lot of work. I
see two separate questions:
1) Should we take steps to make it easier to run the samples in another
database.
2) Should we automate it.
I'd say the first is worth some effort, and the second probably not if they
can be separated.
So, if we have a samples.sql that gets merged into db.script via ant for
the database block using hsql by default and can also be used to manually
create the appropriate tables and sample data in your db of choice, that
would accomplish #1 while stopping short of #2.
Does that KISS?
BTW - there would need to be some logic to determine during the database
build whether the hsql block was installed (and it would need to have been
processed first, right?) before attempting to merge this script with a file
created by the hsql block. Or am I missing something?
Geoff
>cheers
>--
>Torsten
>
>
Re: esql samples
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
>> But the .script file *is* actually a simple .sql script.
>
> Yes, but as I remember it, wouldn't be appropriate to use as the
> source in other DB's, but...
Can you remember why? I haven't really looked closer into it.
>>> Now that the samples are at least working again, how about considering
>>> some options for actually creating the samples "schema" from the .sql?
>>
>> But we could split the cocoondb.script file into
>>
>> cocoondb.setup + cocoondb.sql --ant--> cocoondb.script
>
> that might be all we need.
cool :)
>> So the schema is pretty much the cocoondb.sql file that could also be
>> copied into the samples. Or do you mean a real "schema"?
>
> Sorry, sloppy use of terms. I actually meant "table definitions and
> sample data" for the examples.
ok :)
<snip/>
>> Sorry, I cannot find a good reason on reading the samples entries from
>> an already setup db ;) Why would you want to do this?
>
> Not sure we're understanding each other. I was proposing starting the
> hsql engine "blank" (as it was before you fixed it) and providing a
Did understand that :)
<snip/>
> The only reason approaches like this would have any value would be to
> facilitate using other than hsql db for the samples. If I already have
> mysql installed, I may
> choose to exclude the hsql block.
Don't understand this. Why would you want to try the samples in your db?
I don't really see why we should take the burden on making sure that our
sql creates all tables and data successfully on database X just because
the user wants to run the samples on his database out of the box.
(I mean it's very basic sql - it should not. But I wouldn't take a bet
on any datatype or the primary key definitions. I've seen too much crap
out there;)
Don't take me wrong. I am not against this - but atleast *I* just cannot
see the real value yet. Please tell me :)
cheers
--
Torsten
Re: esql samples
Posted by Geoff Howard <co...@leverageweb.com>.
At 08:46 AM 3/12/2003, Torsten wrote:
><snip/>
>
>>That's why I wouldn't give up too easily on making the db setup work
>>from a normal sql script. Currently we have the .sql out there, but
>>I'm not sure it's up to date (though it looks like it), and if it's
>>not used, it's certainly in danger of getting out of date at some
>>point.
>
>But the .script file *is* actually a simple .sql script.
Yes, but as I remember it, wouldn't be appropriate to use as the
source in other DB's, but...
>>Now that the samples are at least working again, how about considering
>>some options for actually creating the samples "schema" from the .sql?
>
>But we could split the cocoondb.script file into
>
>cocoondb.setup + cocoondb.sql --ant--> cocoondb.script
that might be all we need.
>So the schema is pretty much the cocoondb.sql file that could also be
>copied into the samples. Or do you mean a real "schema"?
Sorry, sloppy use of terms. I actually meant "table definitions and sample
data" for the examples.
><snip/>
>
> > Users could provide the db
>>connection name, which would let them use hsql by default, or any other
>>db they've already set up.
>
>Sorry, I cannot find a good reason on reading the samples entries from an
>already setup db ;) Why would you want to do this?
Not sure we're understanding each other. I was proposing starting the hsql
engine "blank" (as it was before you fixed it) and providing a means of
creating the table structure for the samples and populating the samples
data in it while cocoon runs (and presumably while the user is reading the
database block samples page, following the "in order to use these samples"
instructions that would then be necessary). One idea was to create them
via pipeline (action, sql transformer, etc. - see Chris' email). Another
would be to have a command line script (ant or otherwise).
The only reason approaches like this would have any value would be to
facilitate using other than hsql db for the samples. If I already have
mysql installed, I may
choose to exclude the hsql block.
Geoff
>--
>Torsten
>
>
Re: esql samples
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 12.Mar.2003 -- 08:23 AM, Geoff Howard wrote:
> At 03:39 AM 3/12/2003, you wrote:
> >Well, the idea was to make it easy to switch to $MY_FAVOURITE_DBMS for
> >the user. I believe a frequently asked question is "how do I make the
> >samples work with (MySQL|PostgreSQL|Oracle|DB2|Sybase|Access)?"
>
> That's why I wouldn't give up too easily on making the db setup work
> from a normal sql script. Currently we have the .sql out there, but
> I'm not sure it's up to date (though it looks like it), and if it's
> not used, it's certainly in danger of getting out of date at some
> point.
>
> Now that the samples are at least working again, how about considering
> some options for actually creating the samples "schema" from the .sql?
>
> - Do it during build? HSQL block build? Database block build? Separate
> target?
> - Could we have a pipeline to do this that would be the first link
> on the database block samples page? Users could provide the db connection
> name, which would let them use hsql by default, or any other db they've
> already set up.
Apart from providing the connection name, this sounds reasonable. It
could be the first link on the db samples page. Providing the
connection name would entail that all samples could be switched to it
dynamically as well. I wouldn't want that, because it makes the sames
more complex than necessary.
This would probably be the chance to change the "user" table to
e.g. "users" (other suggestions?) so that more DBMSs are happy
(PostgreSQL?)
But, how to go about it? I reckon we still want this .sql
around. Hence we need to parse it and feed it to the DBMS one
statement at a time.... Could be read in through the util logicsheet
and the string tokenizer using ";" as separator. Don't care about ";"
inside of strings :-|
> - Other ideas?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: esql samples
Posted by Torsten Curdt <tc...@dff.st>.
<snip/>
> That's why I wouldn't give up too easily on making the db setup work
> from a normal sql script. Currently we have the .sql out there, but
> I'm not sure it's up to date (though it looks like it), and if it's
> not used, it's certainly in danger of getting out of date at some
> point.
But the .script file *is* actually a simple .sql script.
> Now that the samples are at least working again, how about considering
> some options for actually creating the samples "schema" from the .sql?
But we could split the cocoondb.script file into
cocoondb.setup + cocoondb.sql --ant--> cocoondb.script
So the schema is pretty much the cocoondb.sql file that could also be
copied into the samples. Or do you mean a real "schema"?
<snip/>
> Users could provide the db
> connection name, which would let them use hsql by default, or any other
> db they've already set up.
Sorry, I cannot find a good reason on reading the samples entries from
an already setup db ;) Why would you want to do this?
--
Torsten
Re: esql samples
Posted by Geoff Howard <co...@leverageweb.com>.
At 03:39 AM 3/12/2003, you wrote:
>On 11.Mar.2003 -- 06:33 PM, Torsten Curdt wrote:
>
> > But since this is only used for the "personal" datasource it doesn't
> > make any sense all to have it configurable in the properties. It's just
> > for the example database. Let's KISS :)
>
>Well, the idea was to make it easy to switch to $MY_FAVOURITE_DBMS for
>the user. I believe a frequently asked question is "how do I make the
>samples work with (MySQL|PostgreSQL|Oracle|DB2|Sybase|Access)?"
>
> Chris.
That's why I wouldn't give up too easily on making the db setup work
from a normal sql script. Currently we have the .sql out there, but
I'm not sure it's up to date (though it looks like it), and if it's
not used, it's certainly in danger of getting out of date at some
point.
Now that the samples are at least working again, how about considering
some options for actually creating the samples "schema" from the .sql?
- Do it during build? HSQL block build? Database block build? Separate
target?
- Could we have a pipeline to do this that would be the first link
on the database block samples page? Users could provide the db connection
name, which would let them use hsql by default, or any other db they've
already set up.
- Other ideas?
Geoff
Re: esql samples
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 11.Mar.2003 -- 06:33 PM, Torsten Curdt wrote:
> >>I wanted to look after the esql samples but found
> >>
> >>1) the hsqldb not being filled (where did we do this before?)
> >
> >
> >I noticed this a few days ago, but haven't had time to write about it.
> >I'm pretty sure from experiencing adding a new table to the demo a month
> >ago that the hsqldb was not built automatically. I had to modify the
> >hsql running on my machine, and commit WEB-INF/db/hsql.script (or
> >whatever) that was created when hsql shut down. I could be wrong. But
> >that's what I remember.
>
> Hm... I see. So it's enough to just copy the sql script into the
> WEB-INF/db location. I'll take look...
Yes, that's what's happening. Nice enough, the db.script is more or
less SQL.
<snip/>
> I think the copy into the db directory should do it.
+1
> >>2) the jdbc url, user and password not being replaced
> >
> >This i'm not sure about, but was it done by filter before?
>
> Yes it was. And the variables are already in the properties.
> As well the build.xml looks like it *should* work (on the first glance).
>
> But since this is only used for the "personal" datasource it doesn't
> make any sense all to have it configurable in the properties. It's just
> for the example database. Let's KISS :)
Well, the idea was to make it easy to switch to $MY_FAVOURITE_DBMS for
the user. I believe a frequently asked question is "how do I make the
samples work with (MySQL|PostgreSQL|Oracle|DB2|Sybase|Access)?"
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: esql samples
Posted by Torsten Curdt <tc...@dff.st>.
>> I wanted to look after the esql samples but found
>>
>> 1) the hsqldb not being filled (where did we do this before?)
>
>
> I noticed this a few days ago, but haven't had time to write about it.
> I'm pretty sure from experiencing adding a new table to the demo a month
> ago that the hsqldb was not built automatically. I had to modify the
> hsql running on my machine, and commit WEB-INF/db/hsql.script (or
> whatever) that was created when hsql shut down. I could be wrong. But
> that's what I remember.
Hm... I see. So it's enough to just copy the sql script into the
WEB-INF/db location. I'll take look...
> I was just getting ready to see if there is an ant call to process a sql
> script over jdbc (I'm sure there is, just don't know ant well enough)
> but I'd make slow progress now as I'm very time limited.
Well, but when do you wanna call the target?
The hsqldb would need to be running.
I think the copy into the db directory should do it.
>> 2) the jdbc url, user and password not being replaced
>
>
> This i'm not sure about, but was it done by filter before?
Yes it was. And the variables are already in the properties.
As well the build.xml looks like it *should* work (on the first glance).
But since this is only used for the "personal" datasource it doesn't
make any sense all to have it configurable in the properties. It's just
for the example database. Let's KISS :)
So if noone is really keen on those properties I'll remove them from the
build. No need to filter then.
--
Torsten
Re: esql samples
Posted by Geoff Howard <co...@leverageweb.com>.
At 11:15 AM 3/11/2003, you wrote:
>I wanted to look after the esql samples but found
>
>1) the hsqldb not being filled (where did we do this before?)
I noticed this a few days ago, but haven't had time to write about it. I'm
pretty sure from experiencing adding a new table to the demo a month ago
that the hsqldb was not built automatically. I had to modify the hsql
running on my machine, and commit WEB-INF/db/hsql.script (or whatever) that
was created when hsql shut down. I could be wrong. But that's what I
remember.
I was just getting ready to see if there is an ant call to process a sql
script over jdbc (I'm sure there is, just don't know ant well enough) but
I'd make slow progress now as I'm very time limited.
>2) the jdbc url, user and password not being replaced
This i'm not sure about, but was it done by filter before?
>Did I miss something with the new build system?
>Can anyone provide me a pointer so I can fix it?
>
>Thanks
>--
>Torsten
>
>
Re: [RT] Cocoon's own publishing system
Posted by Andrew Savory <an...@luminas.co.uk>.
On Tue, 11 Mar 2003, Stefano Mazzocchi wrote:
> Diana Shannon wrote:
>
> > 1. Many, many committers weren't updating release and head branches with
> > their doc updates. It took time to scrutinize differences in the
> > branches, to make sure all relevant docs were in the release branch,
> > which is what is used to generate the web site.
>
> Agreed this is a problem.
>
> Hopefully, now that we have two clearly separated repositories, people
> will document only in the appropriate one.
Woah!
I really don't think we want two sets of documentation, do we? It leads to
unnecessary discrepancies, continuity issues and duplication of effort.
There is no reason that I am aware of that we couldn't have one single set
of documentation, and mark content where appropriate as "2.0 only" or "2.1
only". I'm sure that a cocoon-doc cvs module is the right way to go.
Other than that, the rest of the idea for the publishing system sounds
pretty good.
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk
esql samples
Posted by Torsten Curdt <tc...@dff.st>.
I wanted to look after the esql samples but found
1) the hsqldb not being filled (where did we do this before?)
2) the jdbc url, user and password not being replaced
Did I miss something with the new build system?
Can anyone provide me a pointer so I can fix it?
Thanks
--
Torsten
Re: [RT] Cocoon's own publishing system
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
> At the present time, there is a specific need that I am willing to help
> with. For now, lets just leave it at that. I also fully acknowledge
> that if something better comes along that the cocoon team will switch to
> it. I just don't expect that to happen. ;-)
Don't you dare to push us! ;-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Cocoon's own publishing system
Posted by Sam Ruby <ru...@apache.org>.
Stefano Mazzocchi wrote:
> Sam Ruby wrote:
>
>> Steven Noels wrote:
>>
>>> I'm happy to trigger scripts or check on their regular operations
>>> once they are installed, but am a bit swamped ATM to come up with
>>> some scripts myself.
>>>
>>> So anyone who wants to give it a whirl just tell me and I'll be at
>>> your service. Cronifying "build docs" with some nagging shouldn't be
>>> too hard, IIUC. And the rsync stuff has already been sorted out.
>>
>> I have some scripts that do all that and more.
>>
>> But you already knew that. ;-)
>
> Right. Forrest and Gump should be working more together and share
> resources such as those.
>
> Do you have any ideas on how we could proceed in that sense?
Actually, I do. And I have the patience and persistence to see it
through. Meanwhile, the only way to proceed is one step at a time.
I'll also be totally transparent: my goal is to make the cocoon
community more aware of, and directly interact with, the community that
develops components that are either made use of by cocoon or are used
with cocoon by people.
At the present time, there is a specific need that I am willing to help
with. For now, lets just leave it at that. I also fully acknowledge
that if something better comes along that the cocoon team will switch to
it. I just don't expect that to happen. ;-)
> S.
- Sam Ruby
Re: [RT] Cocoon's own publishing system
Posted by Stefano Mazzocchi <st...@apache.org>.
Sam Ruby wrote:
> Steven Noels wrote:
>
>>
>> I'm happy to trigger scripts or check on their regular operations once
>> they are installed, but am a bit swamped ATM to come up with some
>> scripts myself.
>>
>> So anyone who wants to give it a whirl just tell me and I'll be at
>> your service. Cronifying "build docs" with some nagging shouldn't be
>> too hard, IIUC. And the rsync stuff has already been sorted out.
>
>
> I have some scripts that do all that and more.
>
> But you already knew that. ;-)
Right. Forrest and Gump should be working more together and share
resources such as those.
Do you have any ideas on how we could proceed in that sense?
S.
Re: [RT] Cocoon's own publishing system
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
> Sam Ruby wrote:
>
>> I have some scripts that do all that and more.
>>
>> But you already knew that. ;-)
>
> OK, I'm giving in. Given some time and energy, Cocoon, docs included,
> will be built regularily on cocoondev.org, along with some other
> projects, by means of some tool written by some bearded script guru.
> That guru is now able to install all this expertly by himself.
I presume that means that I have an user id on that machine? If so, let
me know the password (or should I supply my public keys?) and I will
take it from there.
> Which means we only need to make sure Cocoon docs can be built through
> Gump, and we'll be able to do the rsyncing from cocoondev.org.
... which you should be doing anyway. ;-)
What's good about having this done on your own machine is that anybody
with a login to that machine can directly do individual builds
themselves for any project build by gump. Given that the transitive
closure of projects that Cocoon can make use of is large, this can be
very powerful.
There are generic directions on how to do this on the gump webpages, but
what I have found best is to provide timely and specific answers to
specific problems as they arise.
As long as you (plural) are interested in making this work, I'm
interested in helping.
> </Steven>
- Sam Ruby
Re: [RT] Cocoon's own publishing system
Posted by Steven Noels <st...@outerthought.org>.
Sam Ruby wrote:
> I have some scripts that do all that and more.
>
> But you already knew that. ;-)
OK, I'm giving in. Given some time and energy, Cocoon, docs included,
will be built regularily on cocoondev.org, along with some other
projects, by means of some tool written by some bearded script guru.
That guru is now able to install all this expertly by himself.
Which means we only need to make sure Cocoon docs can be built through
Gump, and we'll be able to do the rsyncing from cocoondev.org.
Of course, whenever the Cocoon docs get Forrestized, we'll be able to
switch from Gump to forrestbot.cocoondev.org expertedly guided by my
beardless (I assume) personal hero of the year 2002.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Cocoon's own publishing system
Posted by Sam Ruby <ru...@apache.org>.
Steven Noels wrote:
>
> I'm happy to trigger scripts or check on their regular operations once
> they are installed, but am a bit swamped ATM to come up with some
> scripts myself.
>
> So anyone who wants to give it a whirl just tell me and I'll be at your
> service. Cronifying "build docs" with some nagging shouldn't be too
> hard, IIUC. And the rsync stuff has already been sorted out.
I have some scripts that do all that and more.
But you already knew that. ;-)
- Sam Ruby
Re: [RT] Cocoon's own publishing system
Posted by Diana Shannon <sh...@apache.org>.
On Wednesday, March 12, 2003, at 12:22 PM, Steven Noels wrote:
>
> Stefano Mazzocchi wrote:
>
>> So, should we perform 'forrestization' of our documents to go ahead
>> with the plan?
>
> That's not a strict requirement, just cronifying 'cvs update', 'build
> docs' and some 'cp' to a live website will do ATM IIUC.
Don't forget that the web site has a number of redirects. We need to
copy-over/transform any .htaccess file(s) as necessary for a revised web
site build, not the standard docs build.
Diana
Re: [RT] Cocoon's own publishing system
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> So, should we perform 'forrestization' of our documents to go ahead with
> the plan?
That's not a strict requirement, just cronifying 'cvs update', 'build
docs' and some 'cp' to a live website will do ATM IIUC.
The reason handing out Sam a cocoondev.org account was that Gump would
be the supercron job, and that we make sure docs are included in the our
Gump profile. That way, docs are build along the source code, and we can
rsync them to the live website. Of course, Gump does muc more than just
building our docs, but I figured I could do Sam a favor while I was at
it. I've been away for the day however, so I'm also looking for the
latest update.
Sam...? Any other takers?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Cocoon's own publishing system
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> Sounds good to me.
>
> I learned from Ask on infrastructure@ one can do rsync without an rsync
> daemon on a server, over ssh:
>
> rsync -avz -e ssh /orig/dir/ user@otherbox:/destination/dir/
>
> So cocoondev.org might as well help out as a staging server.
Oh, yes, totally!
>> NOTE: from an operativity point of view, Pier has enough karma to
>> setup everything we need on moof or nagoya, as well as providing
>> accounts for those who want to help running the staging server (I
>> would suspect Jeff and Steven to be interested in helping out,
>> hopefully others as well). We might need to post our plan of action to
>> infrastructure@ once we decide what to do, but since there are no
>> security issues they shouldn't be concerned about it (I've already
>> discussed this architecture and people didn't have objections).
>
>
> You can get a playground and test staging server, accounts and whatnot
> from me until Pier has sorted out moof or upgraded nagoya.
+1
> I'm happy to trigger scripts or check on their regular operations once
> they are installed, but am a bit swamped ATM to come up with some
> scripts myself.
No prob.
> So anyone who wants to give it a whirl just tell me and I'll be at your
> service. Cronifying "build docs" with some nagging shouldn't be too
> hard, IIUC. And the rsync stuff has already been sorted out.
So, should we perform 'forrestization' of our documents to go ahead with
the plan?
S.
Re: [RT] Cocoon's own publishing system
Posted by Steven Noels <st...@outerthought.org>.
Stefano Mazzocchi wrote:
> 1) repository is CVS on icarus. as it is today. no changes required in
> the editing/authoring process (for now, at least)
>
> 2) automated staging server is moof (or nagoya)
>
> I'd suggest to install it on moof (or nagoya) [moof is a macosx server
> donated to the ASF by apple and located in their campus, lots of
> bandwidth and support for final java 1.4.1 as for yesterday, administred
> by the apache instrastructure]
>
> Checkout is done over anoncvs, so no possible compromise from the
> staging server to the repository.
>
> 3) the staging server should work for docs as gump works for nightly
> builds, nagging the appropriate mail list if:
>
> - docs aren't valid
> - links are broken
>
> Note that javadocs and idldocs must be automated as well.
>
> 4) the staging server will regenerate results automatically grabbing the
> changes out of CVS directly. this operation will perform unassisted,
> just like gump. in fact, forrest was born to be the gump alter-ego for
> documentation.
>
> 5) when publishing on production is needed, a person with an account on
> icarus will simply log in and perform a remote rsync between the staging
> area and the server. A simple script with a readme will do the job. I
> estimate it might take less than 60 seconds to update the web site this
> way since the thruput between moof and daedalus is several Mbits.
Sounds good to me.
I learned from Ask on infrastructure@ one can do rsync without an rsync
daemon on a server, over ssh:
rsync -avz -e ssh /orig/dir/ user@otherbox:/destination/dir/
So cocoondev.org might as well help out as a staging server.
> NOTE: from an operativity point of view, Pier has enough karma to setup
> everything we need on moof or nagoya, as well as providing accounts for
> those who want to help running the staging server (I would suspect Jeff
> and Steven to be interested in helping out, hopefully others as well).
> We might need to post our plan of action to infrastructure@ once we
> decide what to do, but since there are no security issues they shouldn't
> be concerned about it (I've already discussed this architecture and
> people didn't have objections).
You can get a playground and test staging server, accounts and whatnot
from me until Pier has sorted out moof or upgraded nagoya.
I'm happy to trigger scripts or check on their regular operations once
they are installed, but am a bit swamped ATM to come up with some
scripts myself.
So anyone who wants to give it a whirl just tell me and I'll be at your
service. Cronifying "build docs" with some nagging shouldn't be too
hard, IIUC. And the rsync stuff has already been sorted out.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] Cocoon's own publishing system
Posted by Gianugo Rabellino <gi...@apache.org>.
Pier Fumagalli wrote:
>
> There are "few" problems with moof... I love that little bundle of fur,
> but.... Memory is only 384 Mb and CPU is just 466 Mhz. It's the same system
> I am running @ work, and it is kinda slow :-(
>
> The other thing is that I still quite didn't figure out why it takes roughly
> 30 seconds to SSH to it... But that might be just some firewall problem.
Have you checked your name resolution configuration? It really sounds
like a timeout on reverse resolution.
> I'd prefer to use Nago for the task, but (again), not before it gets updated
> to Solaris 9 and VXFS. But nagoya, on the other hand, has a slower IO from
> disks on multiple files (it doesn't really like GUMP). I need to see if VXFS
> changes this...
Most probably yes, it will. But never rely on Sun iron if you want
I/O... :-/
>>NOTE: from an operativity point of view, Pier has enough karma to setup
>>everything we need on moof or nagoya, as well as providing accounts for
>>those who want to help running the staging server (I would suspect Jeff
>>and Steven to be interested in helping out, hopefully others as well).
>
>
> Yes, here or there, PLEASE, I need help... And on Nago I can act pretty much
> alone (I know every little bit of software installed on the machine, and
> pretty confident on what goes on)...
Here's help, whenever you need it. If you need a hand, just LMK and I'll
gladly take some dust off my sysadm skills... :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
Re: [RT] Cocoon's own publishing system
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
> So, here is the plan I propose:
>
> 1) repository is CVS on icarus. as it is today. no changes required in
> the editing/authoring process (for now, at least)
>
> 2) automated staging server is moof (or nagoya)
>
> I'd suggest to install it on moof (or nagoya) [moof is a macosx server
> donated to the ASF by apple and located in their campus, lots of
> bandwidth and support for final java 1.4.1 as for yesterday, administred
> by the apache instrastructure]
>
> Checkout is done over anoncvs, so no possible compromise from the
> staging server to the repository.
There are "few" problems with moof... I love that little bundle of fur,
but.... Memory is only 384 Mb and CPU is just 466 Mhz. It's the same system
I am running @ work, and it is kinda slow :-(
The other thing is that I still quite didn't figure out why it takes roughly
30 seconds to SSH to it... But that might be just some firewall problem.
I'd prefer to use Nago for the task, but (again), not before it gets updated
to Solaris 9 and VXFS. But nagoya, on the other hand, has a slower IO from
disks on multiple files (it doesn't really like GUMP). I need to see if VXFS
changes this...
> NOTE: from an operativity point of view, Pier has enough karma to setup
> everything we need on moof or nagoya, as well as providing accounts for
> those who want to help running the staging server (I would suspect Jeff
> and Steven to be interested in helping out, hopefully others as well).
Yes, here or there, PLEASE, I need help... And on Nago I can act pretty much
alone (I know every little bit of software installed on the machine, and
pretty confident on what goes on)...
> We might need to post our plan of action to infrastructure@ once we
> decide what to do, but since there are no security issues they shouldn't
> be concerned about it (I've already discussed this architecture and
> people didn't have objections).
+1...
Pier
Re: [RT] Cocoon's own publishing system (removing "build docs"?)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Hi Stefano,
+1 on your proposal, just two comments below:
> ...4) the staging server will regenerate results automatically...
It would be good to be able to know when/if this has happened when
working on docs.
Either a web page on the staging site with a report of what was done,
logs, or something similar would be useful.
> From a usability point of view we gain:
> ....
> - the site update frequency will hopefully improve, thus improving our
> quality of service.
> ...
I think this might also allow us to remove "build docs" and create docs
exclusively through Forrest.
IMHO having to maintain the docs so that they can be generated both
with Forrest and with Cocoon standalone would be a pain, so we might
want to forget about the standalone generation mode, to make docs
maintenance easier.
-Bertrand
Re: [RT] Cocoon's own publishing system
Posted by Andrew Savory <an...@luminas.co.uk>.
On Wed, 12 Mar 2003, Diana Shannon wrote:
> > - Getting it done quickly enough that changes to docs in 2.0 don't fall
> > through the cracks. I don't know if we could/should somehow "freeze" 2.0
> > docs during the process. This will depend greatly on likely time to
> > completion.
>
> I don't see why a freeze would be a problem. Docs simply aren't updated
> that often. :( We could also have a testing/prototype phase using ant
> scripts to pull content from both repositories.
Ok, that's cool. Freezing relevant doc trees is the right way to go then,
as we really don't want people updating the wrong things.
> Why can't we use page-based metadata for versioning? It's not as
> efficient when your content isn't very granular (e.g. page-based as
> above), but it will work well for faqs/snippets/how-tos ATM and more
> complex docs could be refactored down the road (e.g. topic map
> approach). Embedding "since" in one form or the other sounds kind of
> messy (maintenance and editing-wise) to me, unless it's an attribute of
> some kind. Think what it will be like supporting versions 2.0x, 2.1x,
> 2.2x, ... I'm not an expert here, so I'll defer to those with more CMS
> expertise.
Hmm. Just trying to think of the situations that we need to put version
content in, and how it might be used.
As I understand it, we'll have one set of docs, from which we need to
build documentation for 2.0, 2.1, 2.x. So "build docs" on a given version
would ideally either:
- create docs with ONLY content applicable to the version being built
or
- create docs with flags to say "in version X, ..." (useful for people
to see when they'd need to upgrade/downgrade?)
> > Before you all go "eek!" and run away, most of these fields can be
> > automagically generated either by CVS (contributor, creator, date) or by
> > stylesheets (type and format).
>
> I looked at this about a year ago and thought it not expressive enough
> for our needs. It's isn't obvious to me how/if the above might handle
> software release versioning. Suggestions?
Not sure I follow you here -- do you mean CVS wasn't expressive enough, or
that Dublin Core wasn't expressive enough?
If you mean the former, yes, I guess CVS may be a bit limited in what it
could do ... we may need to use Ant.
If you mean the latter, we could always use Qualified Dublin Core (ie, add
our own subset of tags for a given field, eg creator, to create a richer
markup scheme to cope with whatever else we need to store).
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk
Re: [RT] Cocoon's own publishing system
Posted by Diana Shannon <co...@terracare.com>.
On Wednesday, March 12, 2003, at 09:17 AM, Andrew Savory wrote:
>>
>> Do you have a particular approach in mind? If so, then this discussion
>> should probably continue on cocoon-docs.
>
> Ok: here's what I'd suggest. It may not be the most efficient or
> scientific way, but it will certainly be methodical.
>
> - Create cocoon-doc CVS module
> - Populate with content from cocoon-2.1
> - Remove cocoon-2.1 docs and point at cocoon-doc
> - Individually review 2.0 docs, merging with cocoon-doc content where
> applicable
> - Remove cocoon-2.0 docs and point at cocoon-doc
>
> Problems with this approach:
>
> - Getting it done quickly enough that changes to docs in 2.0 don't fall
> through the cracks. I don't know if we could/should somehow "freeze" 2.0
> docs during the process. This will depend greatly on likely time to
> completion.
I don't see why a freeze would be a problem. Docs simply aren't updated
that often. :( We could also have a testing/prototype phase using ant
scripts to pull content from both repositories.
>
> Also, there seem to be a number of ways to indicate the version in the
> docs. A quick random sample:
>
> xdocs/faq/faq-sitemap.xml:cachability (since 2.1)
> xdocs/howto/howto-flow-debugger.xml:<note>Since: 2.1 2002-12-07</note>
> xdocs/userdocs/matchers/template-matcher.xml:<td>SINCE</td><td>Cocoon
> X.Y</td
> xdocs/faq/faq-xslt.xml:Yes. For Cocoon version 2.0.3
> xdocs/howto/howto-paginator-transformer.xml:Make sure you have the
> version 2.0.3 or greater of Cocoon.
>
> etc etc. So we should probably decide on a standard way to denote all of
> these (I think SINCE is the preferred method?).
Why can't we use page-based metadata for versioning? It's not as
efficient when your content isn't very granular (e.g. page-based as
above), but it will work well for faqs/snippets/how-tos ATM and more
complex docs could be refactored down the road (e.g. topic map
approach). Embedding "since" in one form or the other sounds kind of
messy (maintenance and editing-wise) to me, unless it's an attribute of
some kind. Think what it will be like supporting versions 2.0x, 2.1x,
2.2x, ... I'm not an expert here, so I'll defer to those with more CMS
expertise.
> I'm also wondering if we should take this opportunity to add some good
> quality metadata to the docs, for example using Dublin Core. This will
> add
> some much needed semantisation, make the docs more widely (and
> accurately)
> visible, and all the other benefits usually associated with resource
> description. Here's a possible example:
>
> <?xml version="1.0"?>
> <!DOCTYPE rdf:RDF SYSTEM
> "http://purl.org/dc/schemas/dcmes-xml-20000714.dtd">
>
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:dc="http://purl.org/dc/elements/1.1/">
> <rdf:Description about="http://url.of.page">
> <dc:title/>
> <dc:creator/>
> <dc:subject/>
> <dc:description/>
> <dc:contributor/>
> <dc:publisher>Apache Software Foundation</dc:publisher>
> <dc:date/>
> <dc:type/>
> <dc:format/>
> <dc:language/>
> <dc:relation/>
> <dc:coverage/>
> <dc:identifier/>
> </rdf:Description>
> </rdf:RDF>
>
> Before you all go "eek!" and run away, most of these fields can be
> automagically generated either by CVS (contributor, creator, date) or by
> stylesheets (type and format).
I looked at this about a year ago and thought it not expressive enough
for our needs. It's isn't obvious to me how/if the above might handle
software release versioning. Suggestions?
> This allows some seriously cool stuff: cocoon-docs as RDF/RSS (anyone
> for
> a "cocoon-docs latest additions" news feed?), cocoon-docs as an OAI data
> provider, to name but two.
Sure, let's hope...
> What do you all think?
Great start, Andrew. Thanks.
Diana
Re: [RT] Cocoon's own publishing system
Posted by Andrew Savory <an...@luminas.co.uk>.
[Moved here from cocoon-dev]
On Wed, 12 Mar 2003, Diana Shannon wrote:
> On Tuesday, March 11, 2003, at 03:22 PM, Andrew Savory wrote:
>
> > On Tue, 11 Mar 2003, Diana Shannon wrote:
> >
> >> I agree 100% with Andrew that two "clearly" separated repositories
> >> won't
> >> really improve on what we had. But it's all we have at the moment.
> >
> > Sure. I'm happy to help try and refactor it down to one archive. Or
> > perhaps we could set up cocoon-docs with the content from 2.1 and then
> > go
> > through and import any 2.0 content that is missing? I'm assuming 2.1
> > is a
> > superset of 2.0 content.
>
> You could say that. A majority of the core docs are the same. Only a
> handful of docs are different at the present time. Clearly this will
> start to change is we get more docs for various blocks/samples and if we
> start importing wiki content.
>
> Do you have a particular approach in mind? If so, then this discussion
> should probably continue on cocoon-docs.
Ok: here's what I'd suggest. It may not be the most efficient or
scientific way, but it will certainly be methodical.
- Create cocoon-doc CVS module
- Populate with content from cocoon-2.1
- Remove cocoon-2.1 docs and point at cocoon-doc
- Individually review 2.0 docs, merging with cocoon-doc content where
applicable
- Remove cocoon-2.0 docs and point at cocoon-doc
Problems with this approach:
- Getting it done quickly enough that changes to docs in 2.0 don't fall
through the cracks. I don't know if we could/should somehow "freeze" 2.0
docs during the process. This will depend greatly on likely time to
completion.
Also, there seem to be a number of ways to indicate the version in the
docs. A quick random sample:
xdocs/faq/faq-sitemap.xml:cachability (since 2.1)
xdocs/howto/howto-flow-debugger.xml:<note>Since: 2.1 2002-12-07</note>
xdocs/userdocs/matchers/template-matcher.xml:<td>SINCE</td><td>Cocoon X.Y</td
xdocs/faq/faq-xslt.xml:Yes. For Cocoon version 2.0.3
xdocs/howto/howto-paginator-transformer.xml:Make sure you have the version 2.0.3 or greater of Cocoon.
etc etc. So we should probably decide on a standard way to denote all of
these (I think SINCE is the preferred method?).
I'm also wondering if we should take this opportunity to add some good
quality metadata to the docs, for example using Dublin Core. This will add
some much needed semantisation, make the docs more widely (and accurately)
visible, and all the other benefits usually associated with resource
description. Here's a possible example:
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF SYSTEM
"http://purl.org/dc/schemas/dcmes-xml-20000714.dtd">
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description about="http://url.of.page">
<dc:title/>
<dc:creator/>
<dc:subject/>
<dc:description/>
<dc:contributor/>
<dc:publisher>Apache Software Foundation</dc:publisher>
<dc:date/>
<dc:type/>
<dc:format/>
<dc:language/>
<dc:relation/>
<dc:coverage/>
<dc:identifier/>
</rdf:Description>
</rdf:RDF>
Before you all go "eek!" and run away, most of these fields can be
automagically generated either by CVS (contributor, creator, date) or by
stylesheets (type and format).
This allows some seriously cool stuff: cocoon-docs as RDF/RSS (anyone for
a "cocoon-docs latest additions" news feed?), cocoon-docs as an OAI data
provider, to name but two.
What do you all think?
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk
Re: [RT] Cocoon's own publishing system
Posted by Diana Shannon <sh...@apache.org>.
On Tuesday, March 11, 2003, at 03:22 PM, Andrew Savory wrote:
> On Tue, 11 Mar 2003, Diana Shannon wrote:
>
>> I agree 100% with Andrew that two "clearly" separated repositories
>> won't
>> really improve on what we had. But it's all we have at the moment.
>
> Sure. I'm happy to help try and refactor it down to one archive. Or
> perhaps we could set up cocoon-docs with the content from 2.1 and then
> go
> through and import any 2.0 content that is missing? I'm assuming 2.1
> is a
> superset of 2.0 content.
You could say that. A majority of the core docs are the same. Only a
handful of docs are different at the present time. Clearly this will
start to change is we get more docs for various blocks/samples and if we
start importing wiki content.
Do you have a particular approach in mind? If so, then this discussion
should probably continue on cocoon-docs.
Really glad to know you are interested in helping.
Diana
Re: [RT] Cocoon's own publishing system
Posted by Andrew Savory <an...@luminas.co.uk>.
On Tue, 11 Mar 2003, Diana Shannon wrote:
> I agree 100% with Andrew that two "clearly" separated repositories won't
> really improve on what we had. But it's all we have at the moment.
Sure. I'm happy to help try and refactor it down to one archive. Or
perhaps we could set up cocoon-docs with the content from 2.1 and then go
through and import any 2.0 content that is missing? I'm assuming 2.1 is a
superset of 2.0 content.
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk
Re: [RT] Cocoon's own publishing system
Posted by Diana Shannon <sh...@apache.org>.
On Tuesday, March 11, 2003, at 10:49 AM, Stefano Mazzocchi wrote:
>> 1. Many, many committers weren't updating release and head branches
>> with their doc updates. It took time to scrutinize differences in the
>> branches, to make sure all relevant docs were in the release branch,
>> which is what is used to generate the web site.
>
> Agreed this is a problem.
>
> Hopefully, now that we have two clearly separated repositories, people
> will document only in the appropriate one.
I agree 100% with Andrew that two "clearly" separated repositories won't
really improve on what we had. But it's all we have at the moment.
>
>> 2. Updating the live site repository is time consuming, at least for
>> me, on a slow dial-up connection (I live in a rural area of the US
>> with no broadband option). The api docs directory is the time killer
>> here. I spent eight hours, one night, simply performing a cvs update
>> followed by a cvs commit. The most recent update wasn't so bad. The
>> commit/update took only 2.5 hours.
>
> Oh, god. I didn't know that. This is a shame. I'm sorry Diana. I know
> you don't pay dial-up per-minute fees as we normally do here in europe,
> but still.
No, I don't pay per-minute fees. And what I describe was a worst-case
scenario. Some days are slower than others. It blows my mind, observing
the speed difference, when I perform a cvs update on the xml.apache.org
server.
> we must make a better system.
>
>> 3. I was really excited about Forrest transition, thinking the
>> automation would save me all of the above time which I could devote to
>> docs content. Unfortunately:
>> - only a few committers participated in the trial run, so it seemed to
>> me, interest/support is not that great.
>
> I would like to know the issues that are still left on the table to
> solve and work on them. Forrest is clearly the way to go and the site
> transition give us the opportunity to think about it.
You can read the joint proposal at:
http://wiki.cocoondev.org/Wiki.jsp?page=ForrestProposal
You can check out my How-To (not sure how it works with latest Forrest
version):
http://wiki.cocoondev.org/Wiki.jsp?page=HowToForrestTransition
<snip />
> Please do, those will help, but for now, let's clear the whiteboard and
> start outlining the best publishing system.
<snip why="agree with outline" />
> NOTE: from an operativity point of view, Pier has enough karma to setup
> everything we need on moof or nagoya, as well as providing accounts for
> those who want to help running the staging server (I would suspect Jeff
> and Steven to be interested in helping out, hopefully others as well).
I volunteer.
Thanks.
Diana
[RT] Cocoon's own publishing system
Posted by Stefano Mazzocchi <st...@apache.org>.
Diana Shannon wrote:
>
> On Tuesday, March 11, 2003, at 05:32 AM, Pier Fumagalli wrote:
>
>>
>>> I suggest linking to http://xml.apache.org/cocoon/mirror.cgi#nightly but
>>> I guess that's your intention ;-)
>>
>>
>> Yes, but at that point we'll have to re-build the site once again...
>
>
> Ok, we shouldn't be so limited in rebuilding the site as often as
> necessary.
The wiki shows pretty evidently that our documentation publishing system
is currently too hard to use and to slow to work with. This is evident
when people are even afraid to touch it.
We must fix this.
> Here's why it has been tedious and time consuming in the
> past, at least for me.
Ok, let's start planning something better.
> 1. Many, many committers weren't updating release and head branches with
> their doc updates. It took time to scrutinize differences in the
> branches, to make sure all relevant docs were in the release branch,
> which is what is used to generate the web site.
Agreed this is a problem.
Hopefully, now that we have two clearly separated repositories, people
will document only in the appropriate one.
> 2. Updating the live site repository is time consuming, at least for me,
> on a slow dial-up connection (I live in a rural area of the US with no
> broadband option). The api docs directory is the time killer here. I
> spent eight hours, one night, simply performing a cvs update followed by
> a cvs commit. The most recent update wasn't so bad. The commit/update
> took only 2.5 hours.
Oh, god. I didn't know that. This is a shame. I'm sorry Diana. I know
you don't pay dial-up per-minute fees as we normally do here in europe,
but still.
we must make a better system.
> 3. I was really excited about Forrest transition, thinking the
> automation would save me all of the above time which I could devote to
> docs content. Unfortunately:
> - only a few committers participated in the trial run, so it seemed to
> me, interest/support is not that great.
I would like to know the issues that are still left on the table to
solve and work on them. Forrest is clearly the way to go and the site
transition give us the opportunity to think about it.
> - Forresters seemed to suggest, and I could be wrong, that the live site
> cvs update would **still** be required even with Forrest.
No, not necessarely, but a totally different system must be setup in place.
> Thus, I failed
> to see how the transition would make my volunteer committer life any
> more liberated, since this time killing step was still necessary.
This *must* go away.
> I'm happy to help with updating the site based on the revised cvs mirror
> links discussed in this thread. However, I can't do it until later this
> week. In the future, I think it's better if more committers would share
> the burden of updating the live site cvs every now and then,
> particularly those with greater bandwidth connections. In the hopes that
> this will happen, I'll post detailed instructions on how this can be
> done on wiki. (I've posted email instructions on two separate occasions
> in the past which I will now fine tune.)
Please do, those will help, but for now, let's clear the whiteboard and
start outlining the best publishing system.
- o -
Apache has very high security standards. If our web sites get hacked,
the ASF image of quality and security is damaged. Having easier to
install docs, but lower security is not an option.
This means that every solution must be *designed* around security.
IMO, the metapattern of IoC gives us a lot of security. So, the best
publishing system would be something like:
repository -(generation)-> staging -(publishing)-> production
where
repository is used for storing our documents
stating is the location of the staged documentation
production is the location of the final docs
From a security analysis, a compromise of the staging area is not a big
risk, this means that staging can be automated without major political
issues.
While the above arrows indicate the flow of data, the flow of control
must be inverted to provide complete vertical security:
repository <-(reads from)- staging <-(reads from)- production
- o -
So, here is the plan I propose:
1) repository is CVS on icarus. as it is today. no changes required in
the editing/authoring process (for now, at least)
2) automated staging server is moof (or nagoya)
I'd suggest to install it on moof (or nagoya) [moof is a macosx server
donated to the ASF by apple and located in their campus, lots of
bandwidth and support for final java 1.4.1 as for yesterday, administred
by the apache instrastructure]
Checkout is done over anoncvs, so no possible compromise from the
staging server to the repository.
3) the staging server should work for docs as gump works for nightly
builds, nagging the appropriate mail list if:
- docs aren't valid
- links are broken
Note that javadocs and idldocs must be automated as well.
4) the staging server will regenerate results automatically grabbing the
changes out of CVS directly. this operation will perform unassisted,
just like gump. in fact, forrest was born to be the gump alter-ego for
documentation.
5) when publishing on production is needed, a person with an account on
icarus will simply log in and perform a remote rsync between the staging
area and the server. A simple script with a readme will do the job. I
estimate it might take less than 60 seconds to update the web site this
way since the thruput between moof and daedalus is several Mbits.
- o -
From a usability point of view we gain:
- no need for broadband. This means that people can update the site even
on a GPRS cellphone, or on a slow link in africa.
- we are nagged if things go wrong: continous integration for documents.
- the site update frequency will hopefully improve, thus improving our
quality of service.
From a security point of view:
- we use existing ASF-proven security infrastructure (everything is done
over SSH)
- by keeping the stating server on a different machine and with no
information on how to access the others, we don't create more points of
failure
- o -
NOTE: from an operativity point of view, Pier has enough karma to setup
everything we need on moof or nagoya, as well as providing accounts for
those who want to help running the staging server (I would suspect Jeff
and Steven to be interested in helping out, hopefully others as well).
We might need to post our plan of action to infrastructure@ once we
decide what to do, but since there are no security issues they shouldn't
be concerned about it (I've already discussed this architecture and
people didn't have objections).
Comments and suggestions will be very appreciated.
Thanks.
S.
Re: Snapshot links at Cocoon website
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Diana Shannon wrote:
> 2. Updating the live site repository is time consuming, at least for me,
> on a slow dial-up connection (I live in a rural area of the US with no
> broadband option). The api docs directory is the time killer here. I
> spent eight hours, one night, simply performing a cvs update followed by
> a cvs commit. The most recent update wasn't so bad. The commit/update
> took only 2.5 hours.
If you know things take time, you can nohup your processes, this way
they keep on running after logout. Another very nice tool is "screen".
It gives you virtual terminals inside your terminal emulator. In
addition, you can detach it and attach to it at will. Your commands
continue to run and their output is still on your screen when you
re-attach. Never do admin jobs without it ;-)
Chris.
Re: Snapshot links at Cocoon website
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Andrew Savory" <an...@luminas.co.uk> wrote:
> On Tue, 11 Mar 2003, Diana Shannon wrote:
>
>> 1. Many, many committers weren't updating release and head branches with
>> their doc updates. It took time to scrutinize differences in the
>> branches, to make sure all relevant docs were in the release branch,
>> which is what is used to generate the web site.
>
> Hrm. Did we ever reach a consensus on splitting docs out into a separate
> CVS module? I still think it would be a _really_ good idea, as it makes no
> sense as far as I can tell to maintain two sets of documentation (it's
> hard enough getting people to contribute to it as it is, let's not place
> more barriers in the way!).
It sounds allright for me...
> One more question: is there not a machine where we could run the site
> "live" with Cocoon?
Nagoya... But I want to upgrade it to Solaris 9 and VXFS first... And I'm
waiting for Sun's licenses to come in...
Pier
Re: Snapshot links at Cocoon website
Posted by Andrew Savory <an...@luminas.co.uk>.
On Tue, 11 Mar 2003, Diana Shannon wrote:
> 1. Many, many committers weren't updating release and head branches with
> their doc updates. It took time to scrutinize differences in the
> branches, to make sure all relevant docs were in the release branch,
> which is what is used to generate the web site.
Hrm. Did we ever reach a consensus on splitting docs out into a separate
CVS module? I still think it would be a _really_ good idea, as it makes no
sense as far as I can tell to maintain two sets of documentation (it's
hard enough getting people to contribute to it as it is, let's not place
more barriers in the way!).
One more question: is there not a machine where we could run the site
"live" with Cocoon?
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk
Re: Snapshot links at Cocoon website
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Tuesday, March 11, 2003, at 12:31 PM, Diana Shannon wrote:
>
> On Tuesday, March 11, 2003, at 05:32 AM, Pier Fumagalli wrote:
>
>>
>>> I suggest linking to http://xml.apache.org/cocoon/mirror.cgi#nightly
>>> but
>>> I guess that's your intention ;-)
>>
>> Yes, but at that point we'll have to re-build the site once again...
>
<snip/>
> In the future, I think it's better if more committers would share the
> burden of updating the live site cvs every now and then, particularly
> those with greater bandwidth connections. In the hopes that this will
> happen, I'll post detailed instructions on how this can be done on
> wiki. (I've posted email instructions on two separate occasions in the
> past which I will now fine tune.)
Hi Diana,
Thanks for the effort you are making.
It would be great to have some documentation on this stuff ... we ALL
ought to be able to do it!
regards Jeremy
Re: Snapshot links at Cocoon website
Posted by Diana Shannon <sh...@apache.org>.
On Tuesday, March 11, 2003, at 05:32 AM, Pier Fumagalli wrote:
>
>> I suggest linking to http://xml.apache.org/cocoon/mirror.cgi#nightly
>> but
>> I guess that's your intention ;-)
>
> Yes, but at that point we'll have to re-build the site once again...
Ok, we shouldn't be so limited in rebuilding the site as often as
necessary. Here's why it has been tedious and time consuming in the
past, at least for me.
1. Many, many committers weren't updating release and head branches with
their doc updates. It took time to scrutinize differences in the
branches, to make sure all relevant docs were in the release branch,
which is what is used to generate the web site.
2. Updating the live site repository is time consuming, at least for me,
on a slow dial-up connection (I live in a rural area of the US with no
broadband option). The api docs directory is the time killer here. I
spent eight hours, one night, simply performing a cvs update followed by
a cvs commit. The most recent update wasn't so bad. The commit/update
took only 2.5 hours.
3. I was really excited about Forrest transition, thinking the
automation would save me all of the above time which I could devote to
docs content. Unfortunately:
- only a few committers participated in the trial run, so it seemed to
me, interest/support is not that great.
- Forresters seemed to suggest, and I could be wrong, that the live site
cvs update would **still** be required even with Forrest. Thus, I failed
to see how the transition would make my volunteer committer life any
more liberated, since this time killing step was still necessary.
I'm happy to help with updating the site based on the revised cvs mirror
links discussed in this thread. However, I can't do it until later this
week. In the future, I think it's better if more committers would share
the burden of updating the live site cvs every now and then,
particularly those with greater bandwidth connections. In the hopes that
this will happen, I'll post detailed instructions on how this can be
done on wiki. (I've posted email instructions on two separate occasions
in the past which I will now fine tune.)
Diana
RE: Snapshot links at Cocoon website
Posted by Reinhard Pötz <re...@gmx.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Ok, it's working here as well, but shouldn't the links go
> to cocoon-2.1?
Good question ... I would link to
http://xml.apache.org/cocoon/mirror.cgi#nightly but this would need a
rebuild of the complete site (as Pier pointed out).
But maybe this update can be done directly at the webserver and the CVS
is updated in the same way.
Reinhard
RE: Snapshot links at Cocoon website
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Ok, it's working here as well, but shouldn't the links go
to cocoon-2.1?
Carsten
> -----Original Message-----
> From: Reinhard Pötz [mailto:reinhard_poetz@gmx.net]
> Sent: Tuesday, March 11, 2003 11:55 AM
> To: cocoon-dev@xml.apache.org
> Subject: RE: Snapshot links at Cocoon website
>
>
> > That is the only occurrence of the word "xml-cocoon2" on the
> > server, all other problems are client-cache related...
>
> I checked it again and now the link is correct. Probably a proxy server
> issue because client caching is turned off in all my browsers.
>
> Reinhard
>
RE: Snapshot links at Cocoon website
Posted by Reinhard Pötz <re...@gmx.net>.
> That is the only occurrence of the word "xml-cocoon2" on the
> server, all other problems are client-cache related...
I checked it again and now the link is correct. Probably a proxy server
issue because client caching is turned off in all my browsers.
Reinhard
Re: Snapshot links at Cocoon website
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 11/3/03 7:32, "Reinhard Pötz" <re...@gmx.net> wrote:
>> From: Pier Fumagalli [mailto:pier@betaversion.org]
>>
>> On 10/3/03 7:42, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
>>
>>> b) Let's get the nightly build working asap
>>
>> Carsten, are you talking about the nightly builds (GUMP) or
>> the nightly CVS snapshots???
>>
>> Because if the latter, I was just waiting for the CVS
>> repository split to integrate their automatic checkout back
>> into the snapshotting scripts already ran by "root" on
>> cvs.apache.org...
>>
>> And I've done that (well, just now, but at least one less
>> problem to worry
>> about)
>>
>> http://cvs.apache.org/snapshots/cocoon-2.0/
>> http://cvs.apache.org/snapshots/cocoon-2.1/
>>
>> I also patched the "download" (mirror) page to reflect the change...
>>
>> http://xml.apache.org/cocoon/mirror.cgi#nightly
>
> Currently the link "Dev Snapshots" leads to
> http://xml.apache.org/from-cvs/xml-cocoon2/. Maybe that's the reason why
> it can't be found by many people.
No it doesn't... I just checked... It goes to the quasi-correct
http://cvs.apache.org/from-cvs/cocoon-2.0...
That's what I just did on the server:
/www/xml.apache.org/cocoon # find . -type f | xargs grep 'xml-cocoon2'
./plan/catalog.html: <a href="http://marc.theaimsgroup.com/?l=xml-co
coon-dev&m=100303902726035&w=2">cvs commit: xml-cocoon2 LISCENSE.resol
ver</a>
/www/xml.apache.org/cocoon #
That is the only occurrence of the word "xml-cocoon2" on the server, all
other problems are client-cache related...
> I suggest linking to http://xml.apache.org/cocoon/mirror.cgi#nightly but
> I guess that's your intention ;-)
Yes, but at that point we'll have to re-build the site once again...
Pier