gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] fixing gump
Date Sun, 03 Oct 2004 02:13:37 GMT
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 -> jenny -> user

'jenny' is the codename of the web application that will present the 
gump-generated data to the user.

2) not only the information presented is misleading but I think Gump 
simply operates wrong. take a look at

  http://brutus.apache.org/gump/test/project_todos.html

look at the "cocoon" project. it says that it has "1 affected" and "54 
dependees", then the "deli" project (which is a package that the cocoon 
module exposes) has "2 affected" and "1 dependee". Either there is 
something wrong or i don't understand what is an "affected project" and 
what is a "dependee".

Moreover, right below cocoon there is "cocoon-block-asciiart". Now, this 
project depends directly on "cocoon", but instead of being yellow, it's 
red. This is just wrong.

Scroll down, there are *a ton* of cocoon blocks that should *NOT* have 
been built because their major dependency was missing. I wonder what's 
going on. add "cocoon-lenya" and "xml-forrest" to the list too.

Let's keep going:

3) xom does not have any affected project but has 137 dependees.

but then

http://brutus.apache.org/gump/test/dom4j/dom4j/index.html

tell me that dom4j hasn't been built because of XOM failing. Color me 
surprised, I guess DOM4j was effected by this xom not building.

But let's look at XOM

http://brutus.apache.org/gump/test/xom/index.html

State: Failed
Reason: Synchronize Failed

The update was done ok, so what is this supposed to mean?

4) another thing, the "excalibur issue"

http://brutus.apache.org/gump/test/excalibur/excalibur-pool-api/gump_work/build_excalibur_excalibur-pool-api.html

look at the build dump:

  maven-1.0-beta-10.jar (no download url specified)

we have serious issues with gump/maven integration, we should try a 
little harder on this one.

Note: here the problem is that since this failed, cocoon shouldn't have 
been built since it directly depends on this! [so there are *three* 
level of building that failed because of gump not recognizing 
dependencies properly]

5) what is this supposed to be?

http://brutus.apache.org/gump/test/gump/gump-test/gump_work/buildscript_gump_gump-test.html

enough for now.

I'm diving in the code now, hopefully you'll see patches flying too.

-- 
Stefano.


Mime
View raw message