> 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.
+1. > 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". Hmmm. And again ... Hmmm. I had bad math once before, but I swear I fixed it. Basically of the N dependees that a project could dork up, M (M<=N) dependees could be affected by that project's failure (with N - M being dorked up by some earlier dependency). Do *not* ask me how we get 2 and 1. Some optimization perhaps (this determination once cost far too many cycles). This ought be added to JIRA. > 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. I think this is a result of trying to "build everything every night" ... i.e. it is trying to build off a cocoon in the repository. [Once we tried this I knew things got pretty 'fuzzy'.] > 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. See above. > 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. Again, see above. Clearly there is work to do, or I ought back this out until we have a clear plan. Do we try to build all, or not? If we do, and I think we want to, how do we cope with states when parents are failing, but we have older versions pre-built in the repository. > 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? When we update we checkout to a staging area. We then syncronize that to a working area (historical, but folks like it) and that synchronize failed. I had that with gump-test, the SVN checkout completed, but to an incorrect location -- so the sync then failed. I think I just fixed that, I'll look here at this. > 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. If folks use the Maven gump goal (to generate the Gump descriptor) dependencies ought be correct. That said, this looks like some sort of Maven internal thing. I'm not sure why it is needed. We could post it to JIRA, and see if we could get Brett to help us. > 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] It used to, but now it tries not to. > 5) what is this supposed to be? > > http://brutus.apache.org/gump/test/gump/gump-test/gump_work/buildscript_gump_gump-test.html Some unit tests Gump runs on itself. > enough for now. > > I'm diving in the code now, hopefully you'll see patches flying too. :-) Biggest help is folks looking at the outputs and scrutinizing them, it is the only way Gump improves. regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
