Re: Unnecessary zipping and backups?

2004-11-24 Thread The Web Maestro
Yeah, Glen...
On Nov 23, 2004, at 8:18 PM, Glen Mazza wrote:
Clay,
I'm noticing a lot of .zips and .bak backup files in our cvs 
directories [1] -- this seems unnecessary and a bit messy for a 
version control system, as everyone who cvs checkouts or cvs 
updates is now downloading these files.  Instead of zip files, 
usually the solution is just to cvs remove the files -- they will 
automatically go into the cvs attic as a result (they are not actually 
deleted -- ViewCVS lists them as dead but they are always still 
retrievable.)

For backup files, we can always go to older versions by clicking on 
the first column in ViewCVS ([2], for an example version list).  So I 
don't think we have a need for creating any .bak files either.  If 
there is a message you wish to store with a particular version before 
moving forward, just make a *very* minor change to the file (say, move 
a character or add a blank line), and add your comment when you cvs 
commit.

Can we get these zip's and bak's removed?  Just cvs remove them -- 
get them in the attic so people aren't downloading them on a cvs 
checkout.
I actually added those, so they'd be put in the attic... I'd intended 
to remove them shortly thereafter but I've been a bit busy with... 
erm... other stuff. Thanks for the 'ping' about it!

On a similar note, I am 'contemplating' committing the xml-fop/build/ 
folder ('built' by apache-forrest-0.6). My reasoning for this is 
two-fold: 1. it contains the FOP web site (which I've spent a 
significant amount of time to re-create).
2. it can serve as off-line of documentation (for those installations 
not connected to the internet).

We may not need to do this since it *is* on minotaur.apache.org...
BTW -- thanks *very* much for taking care of the alt-design tab, I 
greatly appreciate the effort in simplifying our site.
Glad to be of service. If there are other things which anyone thinks 
can improve the site (e.g. consolidating pages, removing 
moved/incorrect/inappropriate content, etc.) please let me know.

Thanks,
Glen
[1] http://cvs.apache.org/viewcvs.cgi/xml-fop/
[2] 
http://cvs.apache.org/viewcvs.cgi/xml-fop/build.bat?rev=1.22view=log
Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


Re: Unnecessary zipping and backups?

2004-11-24 Thread The Web Maestro
On Nov 24, 2004, at 11:52 AM, The Web Maestro wrote:
On a similar note, I am 'contemplating' committing the xml-fop/build/ 
folder ('built' by apache-forrest-0.6). My reasoning for this is 
two-fold:
1. it contains the FOP web site (which I've spent a significant amount 
of time to re-create).
2. it can serve as off-line of documentation (for those installations 
not connected to the internet).

We may not need to do this since it *is* on minotaur.apache.org...
I meant to ask FOP-DEV... what are your thoughts on my COMMITTING 
xml-fop's Forrest-generated build/ directory structure?

Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


Re: Unnecessary zipping and backups?

2004-11-24 Thread Glen Mazza
--- The Web Maestro [EMAIL PROTECTED] wrote:

 On Nov 24, 2004, at 11:52 AM, The Web Maestro wrote:
  On a similar note, I am 'contemplating' committing
 the xml-fop/build/ 
  folder ('built' by apache-forrest-0.6). My
 reasoning for this is 
  two-fold:
  1. it contains the FOP web site (which I've spent
 a significant amount 
  of time to re-create).
  2. it can serve as off-line of documentation (for
 those installations 
  not connected to the internet).
 
  We may not need to do this since it *is* on
 minotaur.apache.org...
 
 I meant to ask FOP-DEV... what are your thoughts on
 my COMMITTING 
 xml-fop's Forrest-generated build/ directory
 structure?
 

For #1) Wouldn't we have to keep doing that whenever a
change is made to the website as a result?  I'm
concerned with it falling out of sync with the
production website.

Also, the output on minotaur should be viewable via
ViewCVS anyway, correct?  (We were doing manual
updates to the website to fix the breadcrumb issue--we
went through ViewCVS to find the correct pages to
update IIRC.)  

For #2) Oh ye of little faith! ;) Aren't we eventually
going to have a full-site PDF anyway?  Then
non-internet installations can just save a copy of the
PDF locally after they download the software.  (I
guess they have to be connected at some time to the
'Net though...)  Perhaps saving the full site PDF once
we get it may be more efficient.

Glen



foundation page updated

2004-11-24 Thread Glen Mazza
XML Graphics is now listed on the foundation page,
thanks to David Crossley/Forrest Team:

http://www.apache.org/foundation

Glen



RE: Unnecessary zipping and backups?

2004-11-24 Thread Andreas L. Delmelle
 -Original Message-
 From: Glen Mazza [mailto:[EMAIL PROTECTED]

 --- The Web Maestro [EMAIL PROTECTED] wrote:

  On a similar note, I am 'contemplating' committing
  the xml-fop/build/ folder ('built' by apache-forrest-0.6).
  My reasoning for this is two-fold:
  1. it contains the FOP web site (which I've spent
 a significant amount of time to re-create).

Hmm... since we already offer the source XML for generating the
website --correct?--, wouldn't it be sufficient to point those interested to
Forrest if they want to build the documentation locally? (Maybe even provide
an Ant build-target, of course depending on the presence of Apache Forrest
in the target environment... analogous to the 'javadoc' target)

Those who do not want to take the time, or are unwilling to learn to use
Forrest can still admire the site in all its glory online.

Just a thought.

Greetz,

Andreas



Re: foundation page updated

2004-11-24 Thread The Web Maestro
On Nov 24, 2004, at 1:36 PM, Glen Mazza wrote:
XML Graphics is now listed on the foundation page,
thanks to David Crossley/Forrest Team:
http://www.apache.org/foundation
Glen
Looks like the listed us, but didn't add us to the links in the site 
nav. In addition, does it make sense to add XML Graphics somewhere on 
the xml.apache.org page? They already need to move Forrest (and perhaps 
Lenya, there may be others...).

I'm thinking the should remove FOP  Batik from the Projects heading 
and create:

XML Graphics
* Overview (http://xmlgraphics.apache.org/)
* FOP (http://xml.apache.org/fop/)
* Batik (http://xml.apache.org/batik/)
They could also add some sort of blurb to the CONTENT area on their 
home page about the Apache XML Graphics Project creation and their 
assumption of managing FOP  Batik...

Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


Re: Unnecessary zipping and backups?

2004-11-24 Thread The Web Maestro
On Nov 24, 2004, at 1:39 PM, The Web Maestro wrote:
On Nov 24, 2004, at 1:16 PM, Glen Mazza wrote:
snip
Also, the output on minotaur should be viewable via
ViewCVS anyway, correct?  (We were doing manual
updates to the website to fix the breadcrumb issue--we
went through ViewCVS to find the correct pages to
update IIRC.)
Sort of. minotaur is a different location
(actually I believe minotaur does both, but the *web site* is a 
different location... the rest of my comment is unchanged)

Also, Andreas is correct that the site is built from the source (and I 
didn't forget that! ;-)). As long as the wholesite files are turned 
off, you get a BUILD SUCCESSFUL(!) at the end of a Forrest run.

Web Maestro Clay
--
[EMAIL PROTECTED] - http://homepage.mac.com/webmaestro/
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


RE: Unnecessary zipping and backups?

2004-11-24 Thread Andreas L. Delmelle
 -Original Message-
 From: The Web Maestro [mailto:[EMAIL PROTECTED]

 Also, Andreas is correct that the site is built from the source (and I
 didn't forget that! ;-)).

Yeah, make them sweat at least as hard as you --that way, your effort will
be even more appreciated :-)

Greetz,

Andreas



Re: Unnecessary zipping and backups?

2004-11-24 Thread Peter B. West
The Web Maestro wrote:
BTW -- thanks *very* much for taking care of the alt-design tab, I 
greatly appreciate the effort in simplifying our site.

Glad to be of service. If there are other things which anyone thinks can 
improve the site (e.g. consolidating pages, removing 
moved/incorrect/inappropriate content, etc.) please let me know.
Clay,
Let me say, Clay, thank you *very*, *very* much for taking care of the 
alt-design tab.  Have I drawn your attention to the fact that I am *very 
happy* that you have taken care of this?

(I have thanked Clay personally out-of-band for his work on this.)
Peter


[GUMP@brutus]: Project cocoon-block-fop (in module cocoon) failed

2004-11-24 Thread Gump
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-fop has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-fop :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [fop-block.jar] identifier set to project name
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: xml-fop-maintenance unknown to *this* 
workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/rss.xml
- Atom: http://brutus.apache.org/gump/public/cocoon/cocoon-block-fop/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 18001524112004, brutus:brutus-public:18001524112004
Gump E-mail Identifier (unique within run) #4.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]