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 folk at [EMAIL PROTECTED]
Project gump-test has an issue affecting its community integration, and has been
Stefano Mazzocchi wrote:
This is not a rant, but constructive criticism.
1) as I mentioned already, I think that having gump (or forrest or
whatever) generate static HTML pages creates more problems than it
solves. I think we should move the architecture with something like this
metadata -
Hi gang,
[EMAIL PROTECTED]:/usr/local/gump$ df -h
FilesystemSize Used Avail Use% Mounted on
/dev/sda1 7.4G 1.4G 5.7G 19% /
tmpfs1011M 0 1011M 0% /dev/shm
/dev/sda6 25G 2.1G 21G 9% /home
/dev/sdb6 32G 26G 3.9G 87%
On Sunday 03 October 2004 07:34, Scott Sanders wrote:
it's going to be the simplest thing (for me!) that can possibly work.
which is probably going to be cocoon ;-)
That's a HUGE hammer, I hope you're pounding some big nails :)
http://www.ibiblio.org/Dave/Dr-Fun/df200210/df20021030.jpg
Dear Gumpmeisters,
The following 10 notifys should have been sent
*** G U M P
[EMAIL PROTECTED]: gump failed
[EMAIL PROTECTED]: cocoon-2.1/deli failed
[EMAIL PROTECTED]: smartfrog success, but with warnings.
[EMAIL PROTECTED]:
Dear Gumpmeisters,
The following 1 notifys should have been sent
*** G U M P
[EMAIL PROTECTED]: cocoon-lenya/cocoon-lenya failed
*** G U M P
[EMAIL PROTECTED]:
Leo Simons wrote:
Hi gang,
[EMAIL PROTECTED]:/usr/local/gump$ df -h
FilesystemSize Used Avail Use% Mounted on
/dev/sda1 7.4G 1.4G 5.7G 19% /
tmpfs1011M 0 1011M 0% /dev/shm
/dev/sda6 25G 2.1G 21G 9% /home
/dev/sdb6 32G
Sam Ruby wrote:
Leo Simons wrote:
Hi gang,
[EMAIL PROTECTED]:/usr/local/gump$ df -h
FilesystemSize Used Avail Use% Mounted on
/dev/sda1 7.4G 1.4G 5.7G 19% /
tmpfs1011M 0 1011M 0% /dev/shm
/dev/sda6 25G 2.1G 21G 9% /home
/dev/sdb6
Leo Simons wrote:
Stefano Mazzocchi wrote:
This is not a rant, but constructive criticism.
1) as I mentioned already, I think that having gump (or forrest or
whatever) generate static HTML pages creates more problems than it
solves. I think we should move the architecture with something like
On Monday 04 October 2004 01:29, Stefano Mazzocchi wrote:
So, what do you guys think: should gump metadata still reside in xml
files or should it reside in a database and we have a web application on
top that takes care of managing it?
What is known as Magic, an Ant 1.6 extension system with
Stefano Mazzocchi wrote:
So, what do you guys think: should gump metadata still reside in xml
files or should it reside in a database and we have a web application on
top that takes care of managing it?
If we move, which is probably a good idea, I'd suggest moving over
gradually. Create a
Hi, Adam,
Since it is a class not found, my guess is you might need a new work
entry:
http://gump.apache.org/metadata/project.html#work
I'll keep that in mind, thank you.
Anyway, you ought be able to run:
python gump.py -w metadata/gump.xml ws-jaxme --debug
I tried that, but the
On Monday 04 October 2004 07:02, Stefano Mazzocchi wrote:
now it says that cocoon-block-asciiart didn't build because XOM didn't
build. problem is that that block *DOES NOT* depend on XOM.
This is starting to make me kinda concern.
the old gump was a pain, but at least was working as
Niclas Hedhman wrote:
On Monday 04 October 2004 07:02, Stefano Mazzocchi wrote:
now it says that cocoon-block-asciiart didn't build because XOM didn't
build. problem is that that block *DOES NOT* depend on XOM.
This is starting to make me kinda concern.
the old gump was a pain, but at least was
Example:
http://brutus.apache.org/gump/public/cocoon-2.1/index.html
look at what it says:
SUCCESS
success at what? at finding problems? then it says overall project
success 18%. WTF? what is the measure of success for gump, anything
higher than zero?
True, likely misleading. This is a
This is not a rant, but constructive criticism.
1) as I mentioned already, I think that having gump (or forrest or
whatever) generate static HTML pages creates more problems than it
solves. I think we should move the architecture with something like this
metadata - gump - database -
A cron job such as the following would remove files that are older than
a week:
find /usr/local/gump/public/jars -ctime +6 | xargs -r rm
Ok, now our cron cleanup is:
# Clean up after POI...
0 0 * * * /bin/rm -f /tmp/*.xls
# Clean up older artifacts
0 0 * * * /usr/bin/find
On Monday 04 October 2004 06:04, Stefano Mazzocchi wrote:
well, I'm sorry but I don't get it. Gump *is* querying the metadata for
each module. If you choose to encode your data in a different way and
need to transform it to the gump markup format, that's your problem.
AFAIU, Gump doesn't tell
part of my day job is to deal with tons crappy XML, described by some
even crappier XMLSchema/DTD (most often not in synch!) and try to make
sense of it enough to transform it into RDF.
Since the above pattern can be applied to basically any XML dataset that
grew overtime, it applies very well
19 matches
Mail list logo
