Resigning from Gump PMC
I'd like to resign from the Gump PMC. Usual reason: lack of time and motivation. Given that I had somewhat contributed to Gump over time I thought that I could find the energy to dive into it again, but unfortunately it hasen't been the case. I still would like to retain this possibility though, and remain a committer, but I feel that it's not right that I stay on the PMC. Therefore, since I believe that only PMC member have the right to steer a project, I will not participate any more in votes. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RDBMS preferences
Adam R. B. Jack wrote: If I were to install an RDBMS on Brutus, that can be spoken to by Python, any preferences? MySQL? Firebird? Others? I'm feeling an itch to experiement with this, and I fancy going w/ Firebird 'cos somebody I respect said they prefered it. Any preferences? I have used MySQL with Python without problems. Most projects use MySQL as a reference (maybe because it's more feature limited and thus baseline? ;-) and OS hosting sites usually have it. I'd use MySQL. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Here's a wild idea
Glen Stampoultzis wrote: I was thinking wouldn't it be great to be able to see your projects gump build status straight from your project page. As it is gump spits out html with the build status of each project. What if it also spit out a javascript file that could be included in a projects home page that showed a little green or red ball showing the projects build state? That would be very nice indeed. The easiest thing is that for every project it spits out another page with included only the icon, so that projects can simply include that with Apache include in the pages they want. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [brutus] webapp - why?
Adam R. B. Jack wrote: ... Since we'd rather spend the resources on building than presentation, perhaps we ought just move to the XHTML option (in CleanUp branch). +1 Forrest should be an option, not a strictly necessary dependency. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Was python a good idea?
Stefano Mazzocchi wrote: I have started to use python myself because I loved the much faster try/fail cycle of a scripting language and python looked a lot friendlier than other scripting languages. But in my experience, it doesn't scale in terms of complexity as much as java does. This is my impression also :-( Also, it seems that there is a lot of black magic in getting it to run very solidly, while java has years of polishing on seriously loaded environments. So, I wonder: what would you think about a gump in java? Gump went from Ant to Java and XSLT scripts to Python... now what? ;-) The question I'm asking myself is: what are we trying to solve? Is Java the answer to the Pyhon Gump problems and to all the preceding ones? The first thing I thought was yeah but I'm afraid it's something that will change yet again. Ant and xslt: it was used because it's used to build, so it seemes natural to choose it * cons: complexity (AFAIK) Scripts with xslt: it was used because scripts basically don't give any dependency in Unix environments, and are completely separate from the things that they are building * cons: obscurity and black magic Python: it's a language that many developers know or can learn easily enough, and can be installed in different environments * cons: it isn't as clear as we thought in the first place and seems like a PITA to tune and still not trivial to install Java: it's truly cross-platform and the Gump PMC members all know it quite well; easy to install * cons: dunno Probably before the language we should ask ourselves how the code has to be structured. Maybe we should evaluate the new DOM-based Gump and discuss on that. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using Forrest on teh html docs
Adam R. B. Jack wrote: ... I'll configure that run to use --xdocs (not the default XHTML), or it'll corrupt the webapp. Try doing this: add to the html output all the files that are in the xdocs target *without* the actual xdocs (IOW site.xml, skinconf.xml, tabs.xml, etc, but no index.xml, page.xml) and name the html docs with an .ihtml extension (index.html-index.ihtml, etc). The Forrest webapp should still work. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump work-in-progress (CleanUp branch)
Adam R. B. Jack wrote: ... At the same time the Forrest folk divided to do some major (copyless) work, and they removed the ability to pass work/site location parameters to the batch file. Gump used these. They will be back somehow, don't worry :-) Since I've not managed to install Forrest into TomCat (when I once tried it failed, and the Forrest guys were too busy w/ copyless to fix it), I started to feel the same pain as others. I finally decided I could cope no longer with the *effectively mandatory* Forrest dependency for Gump. The inability for Gump to generate pages w/o Forrest was too much. As it now stands Gump's page generator can now generate XHTML or XDOCS. The XHTML isn't pretty, but with a little CSS it is perfectly adequate [and we get colours again, as it looks w/ might w/ Forrest also]. Forrest can use html instead of xdocs to generate the site. This way we could have a single generation system. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump compatible ant tasks and data types
Niclas Hedhman wrote: On Wednesday 16 June 2004 06:43, Leo Simons wrote: A further goal later on will probably be to have the generation of the gump descriptors execute right before every gump run, which will require a crontab change on brutus and or script change. Really? Can't just the 'Gump Descriptor Generation' be another Gump project?? What Gump would need to support in such case is that the descriptors are re-parsed prior to the invocation, not only at the time of determining the dependency order. In Centipede I had the same problem, and we come up with viprom, but it never really took off as an effort. One possibility is that we add to the Gump descriptor extra elements with their namespace to declare the extra features needed, and then have Gump keep the tags. In this way *any* other program can parse merge.xml and use those values with simple xpath. Another possibility is to have Gump switch to using the Maven descriptor, or a namespaced superset of it... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PROPOSAL: SAX+xmlutils - xml.dom.minidom
Adam R. B. Jack wrote: I just can't seem to deal with the code that Sam originally wrote for parsing/merging XML. ... I can't fix the bugs that are there, I can't extend it without make more bugs, 'odd stuff' happens. This is a problem with all of us that would want to work on Gump. There are many developers that want to put their hands on it, and are stopped by a high entry barrier. Anything to lower this will benefit Gump immensly. We can always come back later to Sam's design at a later date, who knows :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Speed-up Preview
Adam R. B. Jack wrote: I found that the 'annotations' I was allowing on XML elements was somehow clashing with the 'Pythonic' (delegating) 'XML merge' code. Don't ask me why, but removing it allowed a major major metadata load speed-up. Minutes back to seconds. Wow, that's cool! But please help my oor little brain come back to coding after my vacation... what are these 'annotations' you are talking about? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Speed-up Preview
Adam R. B. Jack wrote: ... [and BTW I am looking forward to being able to colour errors as red and warnings as yellow, some day.] I have added a special entry in the new Forrest skinconf for adding extra css, but I still have to check if the class= attribute has been added to the DTD. We have feature-freezed the trunk, let's hope to make a release soon! In any case, thanks for the explanation :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Python 2.3?
Adam R. B. Jack wrote: Do folks mind if we mandate Python 2.3 for Gump? Right now we use Python 2.2 (avoid some methods and bundle the logging classes, and such) for folks like Leo who couldn't get a later RPM (or whatever). Can we upgrade to 2.3? +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven on Gump
Brett Porter wrote: ... BTW, we are getting really close to releasing Maven 1.0, so I'll have some time to set up the gump bootstrap of Maven via ant so you can do this all nicely. I'll send through more info when I get there... From the peanut gallery: your help and efforts are really appreciated, thanks :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gmp
Adam R. B. Jack wrote: ... Let me know what you think. How cute: you help me and also ask permission for it ;-) :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PMC-VOTE] Bylaws
Stefan Bodewig wrote: Instead of replicating the text inside this mail let me just point to the Wiki and say that we are talking about the version of http://wiki.apache.org/gump/Drafts/ProjectBylaws that's been there on 2004-04-13 at 12:00 UTC. I'll simply trust in our Wiki versioning support. Voting will go on for a week and may be closed before that if all PMC members have cast their votes. Stefan Dear PMC members, please cast you votes on the proposed bylaws for the Apache Gump project. +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/bin gmp.bat
Adam R. B. Jack wrote: JAKARTA? ;-) Hey, I just copied gumpy.bat! ;-PP - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 08, 2004 6:31 AM Subject: cvs commit: gump/bin gmp.bat nicolaken2004/04/08 05:31:01 Added: bin gmp.bat ... REM _ J A K A R T A G U M P _ J A K A R T A G U M P _ J A K A R T A G -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout
Adam R. B. Jack wrote: ... Yes, basically page after page of paragraphs/lists/tables. In part 'cos that is all we get with xdocs, in part that is all I think we need. I wish we could abstract the 'data gathering/page forming logic' of this out of class (so we could have HTML or xdoc outputs), and I might try. This code isn't 'bad', but I have a gut feeling it could be a lot better. If anybody has an itch to work with Cheetah, I am more than game to help build a TemplateDocumenter. I could stub one out, if folks were interested. I'd like to work on it, as I have used Velocity recently, and of course I work on Forrest... but I've still not tried again to run Gump. It's unfortunate given that I could do it easily... some time back :-( Ok, so I wanna Gump a subset. Where do I start with the current CVS Gumpy given a W2000 system? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Generating SVG from Python
Adam R. B. Jack wrote: Anybody see an reason (licensing, other) why we should not use this: http://www2.sfk.nl/svg in Gump? It does not seem easier to use than simply outputting SVG as text strings. ... I'd like to use it to generate some SVG images. I believe that some browsers can render [right term?] them raw (IE just seemed to, albeit slowly), but I also believe that Forrest uses Batik to generate PNG (I assume for browser portability). Correct. It also generates svgs and thus pngs from ASCII files: http://incubator.apache.org/incubation/Process_Description.html The source of the image: http://cvs.apache.org/viewcvs.cgi/incubator/site/incubation/incubation-process.aart?view=markup ... I'd like to start simple (perhaps generate some slider type images to show FOG values, etc.) Eventually I'd like to draw some graphs representing dependency tress, etc. For charts I'm getting there. I've finished importing the xml system in JCharts and I'm now working on integrating it in Forrest :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant xdoc proposal output
Antoine Lévy-Lambert wrote: Hi, I would like to publish the html generated by ant xdocs proposals, either directly on the ant.apache.org website, or on another location linked from ant.apache.org. What would be the best way of doing this ? Good question. I have another output to publish too... I tried to use the javadocs publish tag but it's not used in Gumpy and not set on other Gump runs. Hmmm... ideas? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Excalibur under surgical knife
Niclas Hedhman wrote: HI, Just want everyone to know that all of Excalibur is going through some Plastic Surgery, and will take a while before the wound heals. Wound over wound over wound... gosh, this is vivisection! (some may call it autopsy though ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Adam R. B. Jack wrote: I'll certainly guilty of being away for a while, but gump.document.forrest is not a small thing, and to my eyes, not entirely obvious. ... Also, if we want both xdoc and html output we'd need to set of tempaltes (with code in) which isn't nice. Maybe my comment got lost... generate html and Forrest can skin that too. In other words, Forrest can skin an html site. So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I'm -1 on removing Forrest for output, as it takes away the same visual style of the site. IMHO making Forrest skin the html is the most reasonable way to go. Still, I think forrest is a sticking point. I'd like a pure Python solution, and I suspect Cheetah is the best way to go. Cheetah is IMHO the way to go for the basic html rendering. BTW: I'm eager to see some graphics. If SVG can be written (in XML, viua Python) can Forrest convert these to images (using Batik or somethough?) I'll happily continue with Forrest if that is a good way to get images rendered. It's there since some time now. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/profile gump.xml
Martin Cooper wrote: On Sun, 29 Mar 2004 [EMAIL PROTECTED] wrote: server name=brutus type=python status=up attributionApache Organization/attribution Should this be Apache Software Foundation? It should be The Apache Software Foundation. ^ -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump docs solution, makes everyone happy (Re: Gump Thrashing/Spinning...)
Sam Ruby wrote: Nicola Ken Barozzi wrote: ... Maybe my comment got lost... generate html and Forrest can skin that too. In other words, Forrest can skin an html site. So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I'm -1 on removing Forrest for output, as it takes away the same visual style of the site. That's darn near a circular definition. I mean that since I want to keep the site done with Forrest, I would also like to have the other info done that way. To demonstrate: what's wrong with the notion of switching the site to Anakia, which is stable, builds consistently with Gump, and powers www.apache.org, jakarta.apache.org, and a number of other sites? Now realize that I am *NOT* proposing Anakia. What I am proposing is that the ability to view a site as it is being produced is a very valuable thing to have, and an important consideration both for a machine which is a shared resource and for any hope of there ever being personal usage of gump. Errr, did I say that this is not ok? Replay: So, if you make Cheetah output plain html you can see the site natively, or decide to have Forrest skin over it and publish it or use a live Forrest. I am trying to say that I am *+1* to outputting html, but also that Forrest can layer *on top* of that to make a skinned version *if* the user wants to. Note that this does not prevent you from putting a css in the html that Forrest can skin, so that even the non-forrest-skinned version can have nice looks. Is this clear? Beyond that, I would like to reiterate the point that there is value in keeping true to the original design where Gump bootstraps its own dependencies. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: About ForrestCocoon was: Gump Thrashing/Spinning...
Adam Jack wrote: Forrest uses cocoon (http://cocoon.apache.org/2.0/) Which is a servlet that does xml pipelines XML - transform - transform -- xml (or whatever) out. Along with caching all kinds of other cool stuff. That is what you get when you use the forrest run command Because many, many of our pages are never visited this might actually reduce the computational load. Yup, seems highly likely. It also means that if Forrest barfs on a certain page we still get access to the other pages. Forrest can use simple HTML if you save it as *.ihtml My suggestion would be to generate a Forrest usable site with ihtml pages using cheetah, and then publish it so that a dynamic Forrest can show it nicely skinned. This way we get the best of all: 1 - use templates 2 - can see pages without running Forrest 3 - don't even need to run static Forrest -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Project descriptors (was Re: [RT] href considered harmful)
Stefano Mazzocchi wrote: Leo Simons wrote: I suggest we move to strike and loudly proclaim descriptors not living in gump CVS as harmful. Their use needs to be *strongly* discouraged from now on. Who's with me? I agree with you as a general principle. Too bad that the entire cocoon build system relies on the gump descriptor for its blocks and this is going to be so for a while. If you deprecate href, cocoon will be seriously damaged. Now, I am the one to blame for this, Actually I was the one that started it ;-P History: when I needed a descriptor for Centipede, I looked at the Gump one, and extended it. Then Cocoon needed a similar system, so out of my experience with Centipede I created the code-generating block build system but my rationale was to keep gump and cocoon in synch by making sure that everytime you built cocoon, you were also testing if the gump descriptor was right. ...that was what I thought... Of course, only gump can do the full check, but the cocoon build can help a little bit. ... and here is where it broke. The fact is that the two are now so different in the way they work that the check is not good enough. Or we make the Cocoon build system more akin to Gump, or we make something that keeps the two descriptors lazily in synch. Stefano, I need your help. We've been banging our head on this for months, and I still remember a discussion like this with Sam more than a year ago. We *must* resolve this. Let's see: 1. Gump needs to have all the descriptors at hand. Href is too volatile for Gump. 2. Gumpers need to be able to change that information. 3. Project developers need to be able to change that info too. 4. The two descriptors should be able to stey out of synch. So: From point 1 and 2 we need a repository with all the descriptors. From point 3 and 4 we need to have a replication system between the repository and the project. Let's say that each project has a Gump descriptor in the Gump repo and *can* *also* have an href. A cron job can check the two and report the differrences to the respective communities (ie the one that has the oldest descriptor). In this way we have bi-community peer review of changes. Even better, on every descriptor checkin, a quick build is performed with last night's jars, to see that the descriptor works. But this is part of the -build per checkin- thing that is on the agenda in any case. So, is this an option. Let's get this nailed :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
