You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Diana Shannon <sh...@apache.org> on 2002/06/01 12:25:28 UTC
Re: [report] xml-site update
On Friday, May 31, 2002, at 03:37 PM, Vadim Gritsenko wrote:
<snip what="steps of live site update" />
> What are the most significant changes?
I can't speak to the substance of the changes as I myself have not *yet*
committed anything to release. I'm just starting to work my way through
existing files, and I don't have a clear sense of their history *yet*.
You'll have to get feedback from other committers on this. However, it
appears that almost every file changed in some way, along with a few new
additions.
Now that I have done it myself, I will be *very* eager to keep the web
site fresh.
<snip what="more steps" />
>
> 8.
> ssh xml.apache.org
> cd /www/xml.apache.org/cocoon
> cvs ... update
Ahhh... So it appears that you have account privileges on
xml.apache.org. I also see your changes are already live. It is my
understanding that either (1) cron job was scheduled to move files from
the live site repository to this periodically, say, every six hours, or
(2) a committer needs to perform an update on xml.apache.org. The site
doesn't reflect my recent update. Can you help?
Is there a reason why the cron job doesn't appear to be working?
I also forgot to add the step of using Link Alarm
(http://reports.linkalarm.com/373104199608/) to test links, once the
site is live. This should be used primarily for bad external links. I
think we should attempt to catch internal links problems prior to
commits with the live site cvs.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Robert Koberg <ro...@koberg.com>.
Robert Koberg wrote:
> Diana Shannon wrote:
>
>>
>> On Saturday, June 1, 2002, at 08:16 AM, Robert Koberg wrote:
>>
>>>>> I think we should attempt to catch internal links problems prior
>>>>> to commits with the live site cvs.
>>>>>
>>>>
>>>> Yes. The LinkAlarm run will check them too, but that does
>>>> not hurt.
>>>>
>>> It seems so strange that you hard code these things...
>>>
>>> This should never be a problem. I don't understand the reluctance to
>>> use basic XSLT features, but by referencing the link/menu data
>>> through the document function (or whatever the right way is for
>>> cocoon - strange that it has to be different...) you totally
>>> eliminate this problem. If the link exists it is guaranteed to be
>>> correct. If a link 'links' to something that does not exist, either
>>> do not render the <a href/> (just the text) or wrap it in a span
>>> that has font-color:red or something.
>>
>>
>>
>> Part of the problem, Rob, is that we are dealing with static html
>> files that are merged together. The live site is produced from static
>> html files which result from release branch builds -- also html. We
>> have to take partial results of a release branch build (files and
>> directories) and merge with existing live site cvs files and
>> directories. It's inefficient, yes, but Forrest will address this issue.
>
>
> Really, how? Last week I tried to figure it out given the constraints
> of not using the XPath document function or include/import. I could
> not figure out how to do it. I raised the issue about hard-coded links
> on the forrest list and only one person took the time to investigate
> it. I gave a concrete example. Then he (Ivelin) posed the question to
> group asking if the thread was helpful. I think Steven responded
> simply with 'yes.'
>
> So how will forrest address this? Perhaps a nodeset could be created
> and cached to be passed into every transformation?? Or just simply use
> XPath's document function.
Another way to handle it would be to use a cocoon URIResolver and then
you can eliminate the caching problems (for xpath document and xsl
import/include). Perhaps you folks feel this is mixing concerns, but I
see it now that you are removing concerns from something that should be
concerned.
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Ivelin Ivanov <iv...@apache.org>.
Just as a reminder, I also agree with Rob's point of view and would like to
better understand why his suggestions are not commonly acceptable.
----- Original Message -----
From: "Robert Koberg" <ro...@koberg.com>
To: <co...@xml.apache.org>
Sent: Sunday, June 02, 2002 2:47 AM
Subject: Re: [report] xml-site update
> Hi,
>
> Steven Noels wrote:
>
> >Rob,
> >
> >>I don't suppose anybody else could address the issue. Or is Steven the
> >>only one? I believe he was the one who gave the advice to not use
> >>document and include/import. Do others feel that you can/should use
> >>
> >>
> >these?
> >
> >If document() and xsl:import/xsl:include is what you want, i.e. putting
> >everything in one big XSLT transformation (which might be technically
> >possible but hard to maintain),
> >
> It certainly is technically possible (many people already do it this
> way). As for maintenance, I don't understand why you think it is more
> difficult to maintain.
>
> >instead of using the Cocoon pipeline and
> >aggregation approach, I think it will be hard to find partisans for this
> >on this or Forrest's list.
> >
>
> I really want to understand why it is better to use pipelines and
> (sitemap) aggregation in the case of the forrest project.
>
> Anyway... the actual question(which seems to get ignored...) I have been
> asking was: if not this way then how is a cocoon app (forest in
> particular) supposed to handle things that are commonplace in XSLT.
>
> For example, the first question was about xsl:import/xsl:include. I
> offered componentized XSLT for forrest - very clean and very easily
> maintained. You are saying it is easier to maintain by aggregating these
> things through the sitemap rather than using a simple <xsl:include
> href="banner.xsl"/>. Why is it easier to maintain with aggregation?
>
> The second question had to do with using information from the book.xml
> to provide link information (through XPath's document function).
> Currently you hard-code those links. That is hardly something that can
> be considered easily maintainable. How will forrest handle this?
>
> I wanted to provide help to the project but it is set up in a way that
> is very counterintuitive to me.
>
> best,
> -Rob
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Diana Shannon <sh...@apache.org>.
On Sunday, June 2, 2002, at 03:47 AM, Robert Koberg wrote:
> I really want to understand why it is better to use pipelines and
> (sitemap) aggregation in the case of the forrest project.
I think Nicola Ken answered this type of question rather elegantly on
the user's list:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=101864266220351&w=2
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [report] xml-site update
Posted by Steven Noels <st...@outerthought.org>.
Rob,
> Anyway... the actual question(which seems to get ignored...)
> I have been
> asking was: if not this way then how is a cocoon app (forest in
> particular) supposed to handle things that are commonplace in XSLT.
>
> For example, the first question was about xsl:import/xsl:include. I
> offered componentized XSLT for forrest - very clean and very easily
> maintained. You are saying it is easier to maintain by
> aggregating these
> things through the sitemap rather than using a simple <xsl:include
> href="banner.xsl"/>. Why is it easier to maintain with aggregation?
What is your problem with the sitemap doing the aggregation? I'm not
against stylesheet modularization (apart from the obvious cacheing
issues), but not for aggregating different content sources into a single
rendered 'page'.
> The second question had to do with using information from the
> book.xml
> to provide link information (through XPath's document function).
> Currently you hard-code those links. That is hardly something
> that can
> be considered easily maintainable. How will forrest handle this?
I agree the current situation is bearily optimal, and I'm trying to
commit my solution RSN.
> I wanted to provide help to the project but it is set up in a
> way that
> is very counterintuitive to me.
Thanks for trying to help us out, but believe me, many of us have been
doing quite sophisticated XSLT in the past (like you are aiming at), and
Cocoon has been based on the lessons this difficult course taught us.
Decomposing XML transformation into several simple, often parallel
processing steps is consider to be a best practice nowadays, there exist
even submissions to the W3C formalizing this pipeline definition:
http://www.w3.org/TR/xml-pipeline/
HTH,
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
Steven Noels wrote:
>Rob,
>
>>I don't suppose anybody else could address the issue. Or is Steven the
>>only one? I believe he was the one who gave the advice to not use
>>document and include/import. Do others feel that you can/should use
>>
>>
>these?
>
>If document() and xsl:import/xsl:include is what you want, i.e. putting
>everything in one big XSLT transformation (which might be technically
>possible but hard to maintain),
>
It certainly is technically possible (many people already do it this
way). As for maintenance, I don't understand why you think it is more
difficult to maintain.
>instead of using the Cocoon pipeline and
>aggregation approach, I think it will be hard to find partisans for this
>on this or Forrest's list.
>
I really want to understand why it is better to use pipelines and
(sitemap) aggregation in the case of the forrest project.
Anyway... the actual question(which seems to get ignored...) I have been
asking was: if not this way then how is a cocoon app (forest in
particular) supposed to handle things that are commonplace in XSLT.
For example, the first question was about xsl:import/xsl:include. I
offered componentized XSLT for forrest - very clean and very easily
maintained. You are saying it is easier to maintain by aggregating these
things through the sitemap rather than using a simple <xsl:include
href="banner.xsl"/>. Why is it easier to maintain with aggregation?
The second question had to do with using information from the book.xml
to provide link information (through XPath's document function).
Currently you hard-code those links. That is hardly something that can
be considered easily maintainable. How will forrest handle this?
I wanted to provide help to the project but it is set up in a way that
is very counterintuitive to me.
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [report] xml-site update
Posted by Steven Noels <st...@outerthought.org>.
Rob,
> I don't suppose anybody else could address the issue. Or is Steven the
> only one? I believe he was the one who gave the advice to not use
> document and include/import. Do others feel that you can/should use
these?
If document() and xsl:import/xsl:include is what you want, i.e. putting
everything in one big XSLT transformation (which might be technically
possible but hard to maintain), instead of using the Cocoon pipeline and
aggregation approach, I think it will be hard to find partisans for this
on this or Forrest's list.
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Robert Koberg <ro...@koberg.com>.
howdy-do,
Diana Shannon wrote:
>
> On Saturday, June 1, 2002, at 09:29 AM, Robert Koberg wrote:
>
>>>> It seems so strange that you hard code these things...
>>>>
>>>> This should never be a problem. I don't understand the reluctance
>>>> to use basic XSLT features, but by referencing the link/menu data
>>>> through the document function (or whatever the right way is for
>>>> cocoon - strange that it has to be different...) you totally
>>>> eliminate this problem. If the link exists it is guaranteed to be
>>>> correct. If a link 'links' to something that does not exist, either
>>>> do not render the <a href/> (just the text) or wrap it in a span
>>>> that has font-color:red or something.
>>>
>>>
>>>
>>> Part of the problem, Rob, is that we are dealing with static html
>>> files that are merged together. The live site is produced from
>>> static html files which result from release branch builds -- also
>>> html. We have to take partial results of a release branch build
>>> (files and directories) and merge with existing live site cvs files
>>> and directories. It's inefficient, yes, but Forrest will address
>>> this issue.
>>
>>
>> Really, how? Last week I tried to figure it out given the constraints
>> of not using the XPath document function or include/import. I could
>> not figure out how to do it. I raised the issue about hard-coded
>> links on the forrest list and only one person took the time to
>> investigate it. I gave a concrete example. Then he (Ivelin) posed the
>> question to group asking if the thread was helpful. I think Steven
>> responded simply with 'yes.'
>
>
> Give our dear friend Steven a break. Don't you think he had at least
> one slightly more important issue to deal with last week? I'm
> completely amazed he even has time to read emails, let alone respond.
> http://marc.theaimsgroup.com/?l=forrest-dev&m=102235588403970&w=2
arrgghhh... OK... <old-curmudgeon>those damn kids today, always screwing
things up</old-curmudgeon> :) :) :)
I don't suppose anybody else could address the issue. Or is Steven the
only one? I believe he was the one who gave the advice to not use
document and include/import. Do others feel that you can/should use these?
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [report] xml-site update
Posted by Steven Noels <st...@outerthought.org>.
> From: Diana Shannon [mailto:shannon@apache.org]
> Give our dear friend Steven a break. Don't you think he had
> at least one
> slightly more important issue to deal with last week? I'm completely
> amazed he even has time to read emails, let alone respond.
> http://marc.theaimsgroup.com/?l=forrest-dev&m=102235588403970&w=2
Thanks Dia~a :-)
Yes, I happen to be focussed on important issues right now.
</Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Diana Shannon <sh...@apache.org>.
On Saturday, June 1, 2002, at 09:29 AM, Robert Koberg wrote:
>>> It seems so strange that you hard code these things...
>>>
>>> This should never be a problem. I don't understand the reluctance to
>>> use basic XSLT features, but by referencing the link/menu data
>>> through the document function (or whatever the right way is for
>>> cocoon - strange that it has to be different...) you totally
>>> eliminate this problem. If the link exists it is guaranteed to be
>>> correct. If a link 'links' to something that does not exist, either
>>> do not render the <a href/> (just the text) or wrap it in a span that
>>> has font-color:red or something.
>>
>>
>> Part of the problem, Rob, is that we are dealing with static html
>> files that are merged together. The live site is produced from static
>> html files which result from release branch builds -- also html. We
>> have to take partial results of a release branch build (files and
>> directories) and merge with existing live site cvs files and
>> directories. It's inefficient, yes, but Forrest will address this
>> issue.
>
> Really, how? Last week I tried to figure it out given the constraints
> of not using the XPath document function or include/import. I could not
> figure out how to do it. I raised the issue about hard-coded links on
> the forrest list and only one person took the time to investigate it. I
> gave a concrete example. Then he (Ivelin) posed the question to group
> asking if the thread was helpful. I think Steven responded simply with
> 'yes.'
Give our dear friend Steven a break. Don't you think he had at least one
slightly more important issue to deal with last week? I'm completely
amazed he even has time to read emails, let alone respond.
http://marc.theaimsgroup.com/?l=forrest-dev&m=102235588403970&w=2
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Robert Koberg <ro...@koberg.com>.
Diana Shannon wrote:
>
> On Saturday, June 1, 2002, at 08:16 AM, Robert Koberg wrote:
>
>>>> I think we should attempt to catch internal links problems prior to
>>>> commits with the live site cvs.
>>>>
>>>
>>> Yes. The LinkAlarm run will check them too, but that does
>>> not hurt.
>>>
>> It seems so strange that you hard code these things...
>>
>> This should never be a problem. I don't understand the reluctance to
>> use basic XSLT features, but by referencing the link/menu data
>> through the document function (or whatever the right way is for
>> cocoon - strange that it has to be different...) you totally
>> eliminate this problem. If the link exists it is guaranteed to be
>> correct. If a link 'links' to something that does not exist, either
>> do not render the <a href/> (just the text) or wrap it in a span that
>> has font-color:red or something.
>
>
> Part of the problem, Rob, is that we are dealing with static html
> files that are merged together. The live site is produced from static
> html files which result from release branch builds -- also html. We
> have to take partial results of a release branch build (files and
> directories) and merge with existing live site cvs files and
> directories. It's inefficient, yes, but Forrest will address this issue.
Really, how? Last week I tried to figure it out given the constraints of
not using the XPath document function or include/import. I could not
figure out how to do it. I raised the issue about hard-coded links on
the forrest list and only one person took the time to investigate it. I
gave a concrete example. Then he (Ivelin) posed the question to group
asking if the thread was helpful. I think Steven responded simply with
'yes.'
So how will forrest address this? Perhaps a nodeset could be created and
cached to be passed into every transformation?? Or just simply use
XPath's document function.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Diana Shannon <sh...@apache.org>.
On Saturday, June 1, 2002, at 08:16 AM, Robert Koberg wrote:
>>> I think we should attempt to catch internal links problems prior to
>>> commits with the live site cvs.
>>>
>>
>> Yes. The LinkAlarm run will check them too, but that does
>> not hurt.
>>
> It seems so strange that you hard code these things...
>
> This should never be a problem. I don't understand the reluctance to
> use basic XSLT features, but by referencing the link/menu data through
> the document function (or whatever the right way is for cocoon -
> strange that it has to be different...) you totally eliminate this
> problem. If the link exists it is guaranteed to be correct. If a link
> 'links' to something that does not exist, either do not render the <a
> href/> (just the text) or wrap it in a span that has font-color:red or
> something.
Part of the problem, Rob, is that we are dealing with static html files
that are merged together. The live site is produced from static html
files which result from release branch builds -- also html. We have to
take partial results of a release branch build (files and directories)
and merge with existing live site cvs files and directories. It's
inefficient, yes, but Forrest will address this issue.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Robert Koberg <ro...@koberg.com>.
David Crossley wrote:
>Diana Shannon wrote:
><snip/>
>
>
>>I think we should attempt to catch internal links problems prior to
>>commits with the live site cvs.
>>
>>
>
>Yes. The LinkAlarm run will check them too, but that does
>not hurt.
>
It seems so strange that you hard code these things...
This should never be a problem. I don't understand the reluctance to use
basic XSLT features, but by referencing the link/menu data through the
document function (or whatever the right way is for cocoon - strange
that it has to be different...) you totally eliminate this problem. If
the link exists it is guaranteed to be correct. If a link 'links' to
something that does not exist, either do not render the <a href/> (just
the text) or wrap it in a span that has font-color:red or something.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> From: "David Crossley" <cr...@indexgeo.com.au>
>
> > I do have time to schedule LinkAlarm now and then, and to
> > follow up on results. So until the LinkStatusGenerator is
> > working, i will continue with LinkAlarm. Even then, it may
> > be appropriate to still do the occasional run.
>
> +1
>
> LinkStatusGenerator works.
> I've tweaked the contributed sitemap and stylesheet, so it shows coloured
> results.
>
> Where do I put it in the samples?
> It's too small to have a separate sitemap it seems, but then where do I put
> it?
I would place it in a visible location, close to the documentation
section. So that one can click the link and see status of the files,
sort of a poor-man unit test for docs hyperlinks.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "David Crossley" <cr...@indexgeo.com.au>
> I do have time to schedule LinkAlarm now and then, and to
> follow up on results. So until the LinkStatusGenerator is
> working, i will continue with LinkAlarm. Even then, it may
> be appropriate to still do the occasional run.
+1
LinkStatusGenerator works.
I've tweaked the contributed sitemap and stylesheet, so it shows coloured
results.
Where do I put it in the samples?
It's too small to have a separate sitemap it seems, but then where do I put
it?
Thanks :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> David Crossley wrote:
> > Diana Shannon wrote:
> > > David Crossley wrote:
> > > > Diana Shannon wrote:
> > > > <snip/>
> > > >> I also forgot to add the step of using Link Alarm
> > > >> http://reports.linkalarm.com/373104199608/
<snip discussion about LinkAlarm/>
> David,
>
> while I've liked this resource contribution since they day it started, I
> wonder if these resources (money == time) can't be used a little more
> wisely.
>
> Please, please, don't get me wrong: I'm not in PITA-mode, just trying to
> solve potential problems.
>
> If you point your CVS client to the scratchpad, you'll see something
> called "LinkStatusGenerator". There is a sitemap in the
> /mount/linkstatus area that explains its use. I've tried it and it
> works. It might not be perfect, but it's pretty cool stuff.
Wow, there is so much stuff in Cocoon and things that
we do not even know are there.
> LinkAlarm costs 10$ per run but has no initial costs. LinkStatus costs
> 0$ per run but has an initial cost of a few hours, probably more.
> Depending on the value of your hours.
>
> My suggestion is to concentrate on having LinkStatus work with forrest
> sooner rather than later so that we reduce the 'per run' expenses as
> close to zero as possible (which is the only way it can work in the
> longer run for a volunteer no-profit community like this one).
I do not have time to investigate LinkStatusGenerator.
If someone else does, then that would be excellent.
I do have time to schedule LinkAlarm now and then, and to
follow up on results. So until the LinkStatusGenerator is
working, i will continue with LinkAlarm. Even then, it may
be appropriate to still do the occasional run.
> Again, please understand I have nothing against your contribution, but
> I'd like to find an approach that doesn't have per-run costs (neither
> time nor money) associated with it.
No problem. I do see what you mean.
--David
> comments/
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Stefano Mazzocchi <st...@apache.org>.
David Crossley wrote:
>
> Diana Shannon wrote:
> > David Crossley wrote:
> > > Diana Shannon wrote:
> > > <snip/>
> > >> I also forgot to add the step of using Link Alarm
> > >> (http://reports.linkalarm.com/373104199608/) to test links, once the
> > >> site is live. This should be used primarily for bad external links.
> > >
> > > This is a step that only i can do. Our company pays for the
> > > LinkAlarm run. We schedule it on an irregular basis. In the
> > > past this has only been following an official code release,
> > > because that was the only time the website was updated.
> >
> > How generous!
>
> Just one more way that we can contribute. All contributers
> are generous with their time (= money).
>
> > > It looks like there will soon be regular updates of the
> > > website independent of code release. So we will schedule
> > > LinkAlarm to be regular.
> >
> > What does "regular" mean? If I update the live site, I feel somewhat
> > responsible for correcting link errors. How will I know when to check
> > LinkAlarm?
>
> I am not yet sure how often we will run it.
>
> I just scheduled LinkAlarm to do its work again and will tell
> the list when the report is finished.
>
> > I hope this doesn't drive up the costs to your company.
> > I certainly didn't mean to suggest that.
>
> At one cent per page it is not too bad. Last time there were
> 968 pages (it includes javadocs too). So that equates to about
> US$10 per run. We can cope with that.
>
> It is the javadocs that bumps up the page-count. We may decide
> to exclude them. We could then run LinkAlarm more often.
David,
while I've liked this resource contribution since they day it started, I
wonder if these resources (money == time) can't be used a little more
wisely.
Please, please, don't get me wrong: I'm not in PITA-mode, just trying to
solve potential problems.
If you point your CVS client to the scratchpad, you'll see something
called "LinkStatusGenerator". There is a sitemap in the
/mount/linkstatus area that explains its use. I've tried it and it
works. It might not be perfect, but it's pretty cool stuff.
LinkAlarm costs 10$ per run but has no initial costs. LinkStatus costs
0$ per run but has an initial cost of a few hours, probably more.
Depending on the value of your hours.
My suggestion is to concentrate on naving LinkStatus work with forrest
sooner rather than leter so that we reduce the 'per run' expenses as
close to zero as possible (which is the only way it can work in the
longer run for a volunteer no-profit community like this one).
Again, please understand I have nothing against your contribution, but
I'd like to find an approach that doesn't have per-run costs (neither
time nor money) associated with it.
comments/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by David Crossley <cr...@indexgeo.com.au>.
Diana Shannon wrote:
> David Crossley wrote:
> > Diana Shannon wrote:
> > <snip/>
> >> I also forgot to add the step of using Link Alarm
> >> (http://reports.linkalarm.com/373104199608/) to test links, once the
> >> site is live. This should be used primarily for bad external links.
> >
> > This is a step that only i can do. Our company pays for the
> > LinkAlarm run. We schedule it on an irregular basis. In the
> > past this has only been following an official code release,
> > because that was the only time the website was updated.
>
> How generous!
Just one more way that we can contribute. All contributers
are generous with their time (= money).
> > It looks like there will soon be regular updates of the
> > website independent of code release. So we will schedule
> > LinkAlarm to be regular.
>
> What does "regular" mean? If I update the live site, I feel somewhat
> responsible for correcting link errors. How will I know when to check
> LinkAlarm?
I am not yet sure how often we will run it.
I just scheduled LinkAlarm to do its work again and will tell
the list when the report is finished.
> I hope this doesn't drive up the costs to your company.
> I certainly didn't mean to suggest that.
At one cent per page it is not too bad. Last time there were
968 pages (it includes javadocs too). So that equates to about
US$10 per run. We can cope with that.
It is the javadocs that bumps up the page-count. We may decide
to exclude them. We could then run LinkAlarm more often.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Diana Shannon <sh...@apache.org>.
On Saturday, June 1, 2002, at 06:57 AM, David Crossley wrote:
> Diana Shannon wrote:
> <snip/>
>> I also forgot to add the step of using Link Alarm
>> (http://reports.linkalarm.com/373104199608/) to test links, once the
>> site is live. This should be used primarily for bad external links.
>
> This is a step that only i can do. Our company pays for the
> LinkAlarm run. We schedule it on an irregular basis. In the
> past this has only been following an official code release,
> because that was the only time the website was updated.
How generous!
> It looks like there will soon be regular updates of the
> website independent of code release. So we will schedule
> LinkAlarm to be regular.
What does "regular" mean? If I update the live site, I feel somewhat
responsible for correcting link errors. How will I know when to check
LinkAlarm?
I hope this doesn't drive up the costs to your company. I certainly
didn't mean to suggest that.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by David Crossley <cr...@indexgeo.com.au>.
Diana Shannon wrote:
<snip/>
> I also forgot to add the step of using Link Alarm
> (http://reports.linkalarm.com/373104199608/) to test links, once the
> site is live. This should be used primarily for bad external links.
This is a step that only i can do. Our company pays for the
LinkAlarm run. We schedule it on an irregular basis. In the
past this has only been following an official code release,
because that was the only time the website was updated.
It looks like there will soon be regular updates of the
website independent of code release. So we will schedule
LinkAlarm to be regular.
See src/documentation/xdocs/plan/linkalarm-readme.txt
> I think we should attempt to catch internal links problems prior to
> commits with the live site cvs.
Yes. The LinkAlarm run will check them too, but that does
not hurt.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Diana Shannon <sh...@apache.org>.
On Monday, June 3, 2002, at 05:23 AM, Stefano Mazzocchi wrote:
> Vadim Gritsenko wrote:
>
>>> Ahhh... So it appears that you have account privileges on
>>> xml.apache.org.
>>
>> Every committer has. Otherwise, you won't be able to commit your
>> changes
>> (AFAIU this system).
>
> Nop. CVS and HTTPD reside on different machines with different account
> priviledges.
>
> Diana, I'll have root@apache.org give you account priviledges on
> http://xml.apache.org so that you can update the site yourself directly.
>
> Deal?
Deal. Thanks. I'll need a few tips ... :)
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xml.apache.org/cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
> Matthew Langham wrote:
>
>> Great to see the Website updated! Thanks Diana for your hard work! Can I
>> request that we add a couple of additional categories? I had a few
>> emails
>> with Sylvain on this and we came up with:
>>
>>
>>
>> External resources
>> Cocoon consultants (Struts has this)
>> + Links to companies or people providing Cocoon support etc.
>>
>> Success stories
>> + Links to success stories
>>
>> External Sites
>> Cocoon based solutions
>> + Links to companies or people providing Cocoon based solutions
>>
>> <<
>>
>> Did I forget anything Sylvain?
>>
>
> Sorry for the delay, I was off-list since monday.
>
> The list looks ok, and I'd like to detail a bit more the reasons for
> success stories and their content.
Afer reading the post about Ipedo, what about a "Cocoon competitors"
page listing open-source and commercial products that (try to) have a
similar approach ?
This would show that Cocoon is not the only one in its category, but is
clearly the best ;) And once again this is important to attract users.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xml.apache.org/cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Matthew Langham wrote:
>Great to see the Website updated! Thanks Diana for your hard work! Can I
>request that we add a couple of additional categories? I had a few emails
>with Sylvain on this and we came up with:
>
>
>
>External resources
> Cocoon consultants (Struts has this)
> + Links to companies or people providing Cocoon support etc.
>
> Success stories
> + Links to success stories
>
>External Sites
> Cocoon based solutions
> + Links to companies or people providing Cocoon based solutions
>
><<
>
>Did I forget anything Sylvain?
>
Sorry for the delay, I was off-list since monday.
The list looks ok, and I'd like to detail a bit more the reasons for
success stories and their content.
The current Cocoon site is mainly targeted towards *users* of Cocoon,
i.e. people that already made the choice to use Cocoon. We need is
something to attract new users, and the way for this is to show people
*what* they can do with Cocoon before showing them *how* they can do it.
So success stories should start by functional description (the "what"),
followed by a technical description (the "how" : architecture,
components used, etc).
Success stories will also be the place to show all these Cocoon-based
intranet applications that aren't publicly visible on the Internet (all
the projects we made here since 2 years are for intranets).
Finally, showing the wide usage range of Cocoon will allow more people
to consider it as a usable and mature product instead of "just" a nice
innovative technology. This is especially important in large companies
that prefer maturity to technological risk.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Links to commercial entities
Posted by Andy Lewis <aj...@ascii27.net>.
I'm not a committer here - but I think this is a excellent way to handle
it...
> Matthew Langham wrote:
>
>> I discussed this with Sylvain and we both were not sure of the Apache
>> side of things. Perhaps someone can comment on what is "allowed" in
>> the sense of "tolerated". Thanks.
>
> Ok, a few comments from an ASF member.
>
> NOTE: this is *not* official. Only the ASF board can state something
> officially about the ASF, but this is as official as I can get.
>
> First, Apache pays back with visibility, recognition, respect, credits
> and all the non-conservative resources that we can. Paying back with
> non-conservative resources (those that the sum is not constrained,
> unlike money) allows to remove friction from the communities that would
> otherwise develop.
>
> So, rule #1: as long as giving a resource to somebody doesn't remove
> anything from somebody else, no friction will develop and we are all
> set.
>
> Second, Apache is a realist entity. There is no such thing as 'absolute
> freedom' (as some 'free software' persons advocate). In reality, you
> can't eat 'non-conservative resources', well, until we don't have
> startrek-like 'matter compilers', so there is an impedence mistmatch
> that must somehow be solved.
>
> We solved it by allowing people to 'use' their visibility (a
> non-conservative resource) to obtain conservative resources (mostly
> money, but also benefits, such as this very laptop that was kindly
> donated to me some time ago).
>
> Sure, there is the chance of 'abusing' this visibility. This the reason
> why the Apache License prevents you from "stealing" due credits (and
> avoid things like GNU/Linux debates) by abusing the name (you won't see
> a 'RedHat Apache', that's for sure).
>
> Still, there is no problem in letting people who deserve it to be
> listed someplace in the site.
>
> - o -
>
> Now, this said: I personally don't have any problem in having a page
> that lists companies that provide commercial services for Cocoon, as
> long as they deserve it. Unfortunately, there is no such thing as an
> ASF policy for those things and we are allowed to create our own.
>
> So, I would like to propose that a commercial entity that want to be
> listed on those pages *MUST* have submitted at least a patch in the CVS
> at some point and *MUST* be voted in by the committers.
>
> This should remove abuses and keep things sane.
>
> What do you think?
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
--
"The heights of genius are only measurable by the depths of stupiditiy."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Links to commercial entities
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Matthew Langham wrote:
>
>
>
>>I discussed this with Sylvain and we both were not sure of the Apache side
>>of things. Perhaps someone can comment on what is "allowed" in the sense of
>>"tolerated". Thanks.
>>
>>
<snip/>
>Now, this said: I personally don't have any problem in having a page
>that lists companies that provide commercial services for Cocoon, as
>long as they deserve it. Unfortunately, there is no such thing as an ASF
>policy for those things and we are allowed to create our own.
>
>So, I would like to propose that a commercial entity that want to be
>listed on those pages *MUST* have submitted at least a patch in the CVS
>at some point and *MUST* be voted in by the committers.
>
>This should remove abuses and keep things sane.
>
>What do you think?
>
>
>
These are simple but wise rules, as they will reward active members of
the community.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Links to commercial entities
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> <snip>
>
> Now, this said: I personally don't have any problem in having a page
> that lists companies that provide commercial services for Cocoon, as
> long as they deserve it.
I agree here totally, but I see problems in finding out who deserves
it and who not. (There are some companies out there claiming themselfs
to be Cocoon experts which have *NEVER* contributed anything to Cocoon.
And I think they really do not deserve it to be listed!)
> Unfortunately, there is no such thing as an ASF
> policy for those things and we are allowed to create our own.
>
> So, I would like to propose that a commercial entity that want to be
> listed on those pages *MUST* have submitted at least a patch in the CVS
> at some point and *MUST* be voted in by the committers.
>
A patch is one criteria, but perhaps there are more: what about people
answering many questions in the mailing lists but never submitting a
patch etc. This will be very difficult to decide, but we could try it :)
BUT: I don't want to vote on it for two reasons: (ok, I know, if I don't
want to vote I don't have to). First: the community is not
really interested in these votes. So there won't be many votes for a
new entry, I fear. What do we do if only one says: +1 and all the
others remain silent?
But the other thing is that we might get into a competition between two
commercial entities. What if one entity is listed and perhaps
represented by a committer and a competitor wants to be listed, too?
This might create some difficulties, but perhaps I'm too panicing (does
this work exists?) here. I personally have no problems with this, but
others might have (and perhaps the boss of that committer).
> This should remove abuses and keep things sane.
>
> What do you think?
>
As always: we should/could give it a try and see what happens.
Carsten
Carsten Ziegeler Chief Architect Open Source Group, S&N AG
------------------------------------------------------------------
Cocoon Consulting, Training and Projects
------------------------------------------------------------------
mailto:cziegeler@s-und-n.de http://www.s-und-n.de
http://ziegeler.bei.t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Links to commercial entities
Posted by Jeremy Quinn <sh...@mac.com>.
On Tuesday, June 4, 2002, at 10:11 AM, Stefano Mazzocchi wrote:
> Matthew Langham wrote:
>
>> I discussed this with Sylvain and we both were not sure of the
>> Apache side
>> of things. Perhaps someone can comment on what is "allowed" in
>> the sense of
>> "tolerated". Thanks.
>
> So, I would like to propose that a commercial entity that want to be
> listed on those pages *MUST* have submitted at least a patch in the CVS
> at some point and *MUST* be voted in by the committers.
>
> This should remove abuses and keep things sane.
>
> What do you think?
>
Sounds extremely sane to me.
+1
I'll add myself ;)
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Links to commercial entities
Posted by Stefano Mazzocchi <st...@apache.org>.
Matthew Langham wrote:
> I discussed this with Sylvain and we both were not sure of the Apache side
> of things. Perhaps someone can comment on what is "allowed" in the sense of
> "tolerated". Thanks.
Ok, a few comments from an ASF member.
NOTE: this is *not* official. Only the ASF board can state something
officially about the ASF, but this is as official as I can get.
First, Apache pays back with visibility, recognition, respect, credits
and all the non-conservative resources that we can. Paying back with
non-conservative resources (those that the sum is not constrained,
unlike money) allows to remove friction from the communities that would
otherwise develop.
So, rule #1: as long as giving a resource to somebody doesn't remove
anything from somebody else, no friction will develop and we are all
set.
Second, Apache is a realist entity. There is no such thing as 'absolute
freedom' (as some 'free software' persons advocate). In reality, you
can't eat 'non-conservative resources', well, until we don't have
startrek-like 'matter compilers', so there is an impedence mistmatch
that must somehow be solved.
We solved it by allowing people to 'use' their visibility (a
non-conservative resource) to obtain conservative resources (mostly
money, but also benefits, such as this very laptop that was kindly
donated to me some time ago).
Sure, there is the chance of 'abusing' this visibility. This the reason
why the Apache License prevents you from "stealing" due credits (and
avoid things like GNU/Linux debates) by abusing the name (you won't see
a 'RedHat Apache', that's for sure).
Still, there is no problem in letting people who deserve it to be listed
someplace in the site.
- o -
Now, this said: I personally don't have any problem in having a page
that lists companies that provide commercial services for Cocoon, as
long as they deserve it. Unfortunately, there is no such thing as an ASF
policy for those things and we are allowed to create our own.
So, I would like to propose that a commercial entity that want to be
listed on those pages *MUST* have submitted at least a patch in the CVS
at some point and *MUST* be voted in by the committers.
This should remove abuses and keep things sane.
What do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: xml.apache.org/cocoon
Posted by Matthew Langham <ml...@s-und-n.de>.
>>
> This should be the same for "Solutions" also.
Can one sentence sufficiently describe all such solutions?
<<
Probably not - but that is what the link is for. I think any company
offering Cocoon based solutions will have their own site set up for that
sort of thing - and it's only a click away.
I discussed this with Sylvain and we both were not sure of the Apache side
of things. Perhaps someone can comment on what is "allowed" in the sense of
"tolerated". Thanks.
Matthew
-----Original Message-----
From: Diana Shannon [mailto:shannon@apache.org]
Sent: Monday, June 03, 2002 3:08 PM
To: cocoon-dev@xml.apache.org
Subject: Re: xml.apache.org/cocoon
On Monday, June 3, 2002, at 08:52 AM, Matthew Langham wrote:
> We need to make sure that these links are not misused as advertisement -
> correct? I checked the Struts page and they seem to use links only.
> Although
> this is probably the "safest" - my suggestion would be to have a link
> and a
> one sentence description.
I think such descriptions are user-friendly. Why download a whole page
to determine relevancy? We can always edit a submission if someone takes
undue advantage.
> Is this allowed?
*I* have no problem with it.
> Example for consulting:
>
>>>
> <link>S & N AG </link>
> The open source group at S&N AG, Paderborn, Germany, offers consulting
> services and support for Cocoon.
> <<
>
> This should be the same for "Solutions" also.
Can one sentence sufficiently describe all such solutions?
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xml.apache.org/cocoon
Posted by Diana Shannon <sh...@apache.org>.
On Monday, June 3, 2002, at 08:52 AM, Matthew Langham wrote:
> We need to make sure that these links are not misused as advertisement -
> correct? I checked the Struts page and they seem to use links only.
> Although
> this is probably the "safest" - my suggestion would be to have a link
> and a
> one sentence description.
I think such descriptions are user-friendly. Why download a whole page
to determine relevancy? We can always edit a submission if someone takes
undue advantage.
> Is this allowed?
*I* have no problem with it.
> Example for consulting:
>
>>>
> <link>S & N AG </link>
> The open source group at S&N AG, Paderborn, Germany, offers consulting
> services and support for Cocoon.
> <<
>
> This should be the same for "Solutions" also.
Can one sentence sufficiently describe all such solutions?
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: xml.apache.org/cocoon
Posted by Matthew Langham <ml...@s-und-n.de>.
I have a question concerning these links:
> Cocoon consultants (Struts has this)
> + Links to companies or people providing Cocoon support etc.
> External Sites
> Cocoon based solutions
> + Links to companies or people providing Cocoon based solutions
We need to make sure that these links are not misused as advertisement -
correct? I checked the Struts page and they seem to use links only. Although
this is probably the "safest" - my suggestion would be to have a link and a
one sentence description. Is this allowed?
Example for consulting:
>>
<link>S & N AG </link>
The open source group at S&N AG, Paderborn, Germany, offers consulting
services and support for Cocoon.
<<
This should be the same for "Solutions" also.
What do you think?
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=================================================================
-----Original Message-----
From: Diana Shannon [mailto:shannon@apache.org]
Sent: Monday, June 03, 2002 12:39 PM
To: cocoon-dev@xml.apache.org
Subject: Re: xml.apache.org/cocoon
On Monday, June 3, 2002, at 06:06 AM, Matthew Langham wrote:
> External resources
> Cocoon consultants (Struts has this)
> + Links to companies or people providing Cocoon support etc.
Great.
> Success stories
> + Links to success stories
Yes, links are great but success stories, hosted on the Cocoon site, are
even better. I want to add this as a contributor document type. I
haven't written a how-to yet. My hope was that it could fill in some
meaningful details behind-the-scenes details about the live site links
Cocoon currently has. It would have to be a balance: it shouldn't be
purely promotional, nor should it (necessarily) give away all of a
developers "trade secrets". Still, it would give other Cocoon users
tangible examples of what could be done, and how a particular problem
was approached.
> External Sites
> Cocoon based solutions
> + Links to companies or people providing Cocoon based solutions
Great.
Care to provide a patch?
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: xml.apache.org/cocoon
Posted by Matthew Langham <ml...@s-und-n.de>.
Hi,
>>
Care to provide a patch?
<<
I will do.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=================================================================
-----Original Message-----
From: Diana Shannon [mailto:shannon@apache.org]
Sent: Monday, June 03, 2002 12:39 PM
To: cocoon-dev@xml.apache.org
Subject: Re: xml.apache.org/cocoon
On Monday, June 3, 2002, at 06:06 AM, Matthew Langham wrote:
> External resources
> Cocoon consultants (Struts has this)
> + Links to companies or people providing Cocoon support etc.
Great.
> Success stories
> + Links to success stories
Yes, links are great but success stories, hosted on the Cocoon site, are
even better. I want to add this as a contributor document type. I
haven't written a how-to yet. My hope was that it could fill in some
meaningful details behind-the-scenes details about the live site links
Cocoon currently has. It would have to be a balance: it shouldn't be
purely promotional, nor should it (necessarily) give away all of a
developers "trade secrets". Still, it would give other Cocoon users
tangible examples of what could be done, and how a particular problem
was approached.
> External Sites
> Cocoon based solutions
> + Links to companies or people providing Cocoon based solutions
Great.
Care to provide a patch?
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: xml.apache.org/cocoon
Posted by Diana Shannon <sh...@apache.org>.
On Monday, June 3, 2002, at 06:06 AM, Matthew Langham wrote:
> External resources
> Cocoon consultants (Struts has this)
> + Links to companies or people providing Cocoon support etc.
Great.
> Success stories
> + Links to success stories
Yes, links are great but success stories, hosted on the Cocoon site, are
even better. I want to add this as a contributor document type. I
haven't written a how-to yet. My hope was that it could fill in some
meaningful details behind-the-scenes details about the live site links
Cocoon currently has. It would have to be a balance: it shouldn't be
purely promotional, nor should it (necessarily) give away all of a
developers "trade secrets". Still, it would give other Cocoon users
tangible examples of what could be done, and how a particular problem
was approached.
> External Sites
> Cocoon based solutions
> + Links to companies or people providing Cocoon based solutions
Great.
Care to provide a patch?
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
xml.apache.org/cocoon
Posted by Matthew Langham <ml...@s-und-n.de>.
Great to see the Website updated! Thanks Diana for your hard work! Can I
request that we add a couple of additional categories? I had a few emails
with Sylvain on this and we came up with:
>>
External resources
Cocoon consultants (Struts has this)
+ Links to companies or people providing Cocoon support etc.
Success stories
+ Links to success stories
External Sites
Cocoon based solutions
+ Links to companies or people providing Cocoon based solutions
<<
Did I forget anything Sylvain?
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
=================================================================
-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: Monday, June 03, 2002 11:24 AM
To: cocoon-dev@xml.apache.org
Subject: Re: [report] xml-site update
Vadim Gritsenko wrote:
> > Ahhh... So it appears that you have account privileges on
> > xml.apache.org.
>
> Every committer has. Otherwise, you won't be able to commit your changes
> (AFAIU this system).
Nop. CVS and HTTPD reside on different machines with different account
priviledges.
Diana, I'll have root@apache.org give you account priviledges on
http://xml.apache.org so that you can update the site yourself directly.
Deal?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> > Ahhh... So it appears that you have account privileges on
> > xml.apache.org.
>
> Every committer has. Otherwise, you won't be able to commit your changes
> (AFAIU this system).
Nop. CVS and HTTPD reside on different machines with different account
priviledges.
Diana, I'll have root@apache.org give you account priviledges on
http://xml.apache.org so that you can update the site yourself directly.
Deal?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [report] xml-site update
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Diana Shannon [mailto:shannon@apache.org]
>
>
> On Saturday, June 1, 2002, at 02:51 PM, Vadim Gritsenko wrote:
>
> >> <snip what="more steps" />
> >>>
> >>> 8.
> >>> ssh xml.apache.org
> >>> cd /www/xml.apache.org/cocoon
> >>> cvs ... update
> >>
> >> Ahhh... So it appears that you have account privileges on
> >> xml.apache.org.
> >
> > Every committer has. Otherwise, you won't be able to commit your
changes
> > (AFAIU this system).
>
> I don't have privileges there. Ivelin tried it recently and wasn't
> successful either.
Hm.
> >> (2) a committer needs to perform an update on xml.apache.org. The
site
> >> doesn't reflect my recent update. Can you help?
DONE. Please check how it went.
> > What do you want me to update? Whole cocoon site or some parts of
it?
>
> Everything in xml-site/targets/cocoon except apidocs/ and dist/
>
> How do you do this? Is www/xml.apache.org/cocoon yet another cvs? Or
do
www/xml.apache.org/cocoon is a CVS working directory, checked out from
xml-site/target/cocoon.
> you simply copy files into it?
Just "cvs update".
> Can you let me know specifically what you
> do so I can add it to my How-To.
I did:
cd /www/xml.apache.org/cocoon/
cvs update -Pd
That's it.
> >> Is there a reason why the cron job doesn't appear to be working?
> >
> > I don't know about this cron job... I did not know about xml-site
CVS
> > till yesterday ;)
>
> I just heard about it from Steven on this list. Carsten pointed to
> instructions on http://xml.apache.org/guidelines.html, but they don't
> mention anything about the cron job.
There is a doc on Jakarta on how to update site:
http://jakarta.apache.org/site/jakarta-site2.html
Vadim
> Thanks Vadim.
>
> Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [report] xml-site update
Posted by Diana Shannon <sh...@apache.org>.
On Saturday, June 1, 2002, at 02:51 PM, Vadim Gritsenko wrote:
>> <snip what="more steps" />
>>>
>>> 8.
>>> ssh xml.apache.org
>>> cd /www/xml.apache.org/cocoon
>>> cvs ... update
>>
>> Ahhh... So it appears that you have account privileges on
>> xml.apache.org.
>
> Every committer has. Otherwise, you won't be able to commit your changes
> (AFAIU this system).
I don't have privileges there. Ivelin tried it recently and wasn't
successful either.
>> (2) a committer needs to perform an update on xml.apache.org. The site
>> doesn't reflect my recent update. Can you help?
>
> What do you want me to update? Whole cocoon site or some parts of it?
Everything in xml-site/targets/cocoon except apidocs/ and dist/
How do you do this? Is www/xml.apache.org/cocoon yet another cvs? Or do
you simply copy files into it? Can you let me know specifically what you
do so I can add it to my How-To.
>> Is there a reason why the cron job doesn't appear to be working?
>
> I don't know about this cron job... I did not know about xml-site CVS
> till yesterday ;)
I just heard about it from Steven on this list. Carsten pointed to
instructions on http://xml.apache.org/guidelines.html, but they don't
mention anything about the cron job.
Thanks Vadim.
Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [report] xml-site update
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Diana Shannon [mailto:shannon@apache.org]
>
> On Friday, May 31, 2002, at 03:37 PM, Vadim Gritsenko wrote:
...
> Now that I have done it myself, I will be *very* eager to keep the web
> site fresh.
Sounds promising...
> <snip what="more steps" />
> >
> > 8.
> > ssh xml.apache.org
> > cd /www/xml.apache.org/cocoon
> > cvs ... update
>
> Ahhh... So it appears that you have account privileges on
> xml.apache.org.
Every committer has. Otherwise, you won't be able to commit your changes
(AFAIU this system).
> I also see your changes are already live.
I've fixed broken image link...
> It is my
> understanding that either (1) cron job was scheduled to move files
from
> the live site repository to this periodically, say, every six hours,
or
> (2) a committer needs to perform an update on xml.apache.org. The site
> doesn't reflect my recent update. Can you help?
What do you want me to update? Whole cocoon site or some parts of it?
> Is there a reason why the cron job doesn't appear to be working?
I don't know about this cron job... I did not know about xml-site CVS
till yesterday ;)
Vadim
> I also forgot to add the step of using Link Alarm
> (http://reports.linkalarm.com/373104199608/) to test links, once the
> site is live. This should be used primarily for bad external links. I
> think we should attempt to catch internal links problems prior to
> commits with the live site cvs.
>
> Diana
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org