cvs commit: gump/project avalon-excalibur.xml
mcconnell2004/03/24 00:10:26 Modified:project avalon-excalibur.xml Log: Fix excalibur-monitor build failure through addition of a mkdir. Revision ChangesPath 1.123 +2 -0 gump/project/avalon-excalibur.xml Index: avalon-excalibur.xml === RCS file: /home/cvs/gump/project/avalon-excalibur.xml,v retrieving revision 1.122 retrieving revision 1.123 diff -u -r1.122 -r1.123 --- avalon-excalibur.xml 23 Mar 2004 10:11:41 - 1.122 +++ avalon-excalibur.xml 24 Mar 2004 08:10:26 - 1.123 @@ -625,6 +625,8 @@ depend project=junit/ home nested=monitor/ +mkdir dir=monitor/target/classes/ +mkdir dir=monitor/target/test-classes/ work nested=monitor/target/classes/ work nested=monitor/target/test-classes/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project checkstyle.xml
bodewig 2004/03/24 00:10:38 Modified:project checkstyle.xml Log: fix work directory Revision ChangesPath 1.24 +1 -1 gump/project/checkstyle.xml Index: checkstyle.xml === RCS file: /home/cvs/gump/project/checkstyle.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- checkstyle.xml23 Mar 2004 06:39:07 - 1.23 +++ checkstyle.xml24 Mar 2004 08:10:38 - 1.24 @@ -79,7 +79,7 @@ depend project=checkstyle inherit=runtime/ depend project=junit/ -work nested=target/tests/ +work nested=target/checkstyle/ nag from=Conor MacNeill lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED]/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project castor.xml
bodewig 2004/03/24 00:17:39 Modified:project castor.xml Log: Make castor build. There is some logic inside the build file that only works if Ant is invoked from the top level directory, not inside src. It now compiles some tests, so it needs junit. Revision ChangesPath 1.27 +2 -1 gump/project/castor.xml Index: castor.xml === RCS file: /home/cvs/gump/project/castor.xml,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- castor.xml24 Mar 2004 07:58:25 - 1.26 +++ castor.xml24 Mar 2004 08:17:39 - 1.27 @@ -26,7 +26,7 @@ project name=castor packageorg.exolab.castor/package -ant basedir=src target=jar +ant buildfile=src/build.xml target=jar property name=version value=@@DATE@@/ /ant depend project=ant inherit=runtime/ @@ -37,6 +37,7 @@ depend project=jakarta-regexp/ depend project=jakarta-oro/ depend project=commons-logging/ +depend project=junit/ work nested=build/classes/ home nested=dist/ jar name=castor-@@DATE@@.jar/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/profile apache-avalon.xml
mcconnell2004/03/24 00:36:37 Modified:profile apache-avalon.xml Log: Add avalon-legacy. Revision ChangesPath 1.5 +1 -0 gump/profile/apache-avalon.xml Index: apache-avalon.xml === RCS file: /home/cvs/gump/profile/apache-avalon.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- apache-avalon.xml 27 Feb 2004 08:56:56 - 1.4 +++ apache-avalon.xml 24 Mar 2004 08:36:37 - 1.5 @@ -27,5 +27,6 @@ module href=project/avalon-logkit.xml/ module href=project/avalon-phoenix.xml/ module href=project/avalon-site.xml/ + module href=project/avalon-legacy.xml/ /profile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Stefano Mazzocchi wrote: Adam, I think we should get rid of FoG entirely until we have a better solution. It is causing more harm than good. Don't get rid of it. I'd like to sugegst two simple changes that I think would really help the community out: * Rename it to Friendship factor * Provide a link to a page that describes the metric, *every* place the metric appears. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Michael Davey wrote: Don't get rid of it. I'd like to sugegst two simple changes that I think would really help the community out: * Rename it to Friendship factor * Provide a link to a page that describes the metric, *every* place the metric appears. +1 -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project avalon-legacy.xml avalon.xml
On 24 Mar 2004, [EMAIL PROTECTED] wrote: module name=avalon-legacy url href=http://avalon.apache.org// description Avalon's main repository. /description cvs repository=avalon/ This will try to check out the CVS module avalon-legacy from cvs.apache.org, which doesn't exist. Is the code still inside the avalon module? If so, please use cvs repository=avalon module=avalon/ in the descriptor. Cheers Stefan -- http://stefanbodewig.blogger.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project antlr.xml jakarta-slide.xml
bodewig 2004/03/24 05:44:00 Modified:profile gump.xml project antlr.xml jakarta-slide.xml Log: Antlr 2.7.3 Revision ChangesPath 1.328 +1 -1 gump/profile/gump.xml Index: gump.xml === RCS file: /home/cvs/gump/profile/gump.xml,v retrieving revision 1.327 retrieving revision 1.328 diff -u -r1.327 -r1.328 --- gump.xml 23 Mar 2004 06:56:08 - 1.327 +++ gump.xml 24 Mar 2004 13:44:00 - 1.328 @@ -263,7 +263,7 @@ !-- Installed packages -- - project name=antlrpackage=antlr-2.7.2/ + project name=antlrpackage=antlr-2.7.3/ project name=aspectj package=aspectj1.1/ project name=concurrent package=dougLea/ project name=cos package=cos-05Nov2002/ 1.3 +1 -2 gump/project/antlr.xml Index: antlr.xml === RCS file: /home/cvs/gump/project/antlr.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- antlr.xml 27 Feb 2004 09:22:56 - 1.2 +++ antlr.xml 24 Mar 2004 13:44:00 - 1.3 @@ -23,9 +23,8 @@ project name=antlr packageantlr/package -!-- untpack antlr 2.7.2, run ./configure; make antlrall.jar -- -jar name=antlrall.jar id=antlr-tools/ +!--jar name=antlrall.jar id=antlr-tools/-- jar name=antlr.jar id=antlr/ /project /module 1.56 +1 -1 gump/project/jakarta-slide.xml Index: jakarta-slide.xml === RCS file: /home/cvs/gump/project/jakarta-slide.xml,v retrieving revision 1.55 retrieving revision 1.56 diff -u -r1.55 -r1.56 --- jakarta-slide.xml 10 Mar 2004 21:26:45 - 1.55 +++ jakarta-slide.xml 24 Mar 2004 13:44:00 - 1.56 @@ -45,7 +45,7 @@ property name=taglibs-standard.jar project=jakarta-taglibs-standard id=standard reference=jarpath/ depend property=antlr.jar project=antlr id=antlr / - depend property=antlr-tools.jar project=antlr id=antlr-tools / + depend property=antlr-tools.jar project=antlr id=antlr / depend property=jdbc20ext.jar project=jdbc / depend property=commons-modeler.jar project=commons-modeler/ depend property=jndi.jar project=jndi/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/template/forrest/src/documentation/content/xdocs site.xml
ajack 2004/03/24 07:51:42
Modified:python/gump/document forrest.py
template/forrest/src/documentation/content/xdocs site.xml
Log:
Generate a 'notes log', a page showing the annotations on modules/project, IFF the
module/project has 'nasties' (warnings/errors).
There are numerous notes being made on projects, and I doubt many are being
reviewed...
Revision ChangesPath
1.115 +50 -5 gump/python/gump/document/forrest.py
Index: forrest.py
===
RCS file: /home/cvs/gump/python/gump/document/forrest.py,v
retrieving revision 1.114
retrieving revision 1.115
diff -u -r1.114 -r1.115
--- forrest.py24 Mar 2004 15:19:22 - 1.114
+++ forrest.py24 Mar 2004 15:51:42 - 1.115
@@ -473,6 +473,51 @@
if not pcount: projectsTable.createLine('None')
document.serialize()
+
+#
+# --
+#
+# notesLog.xml -- Notes log
+#
+document=XDocDocument('Annotations', \
+self.resolver.getFile(workspace,'notesLog'))
+self.documentSummary(document, workspace.getProjectSummary())
+
+notesSection=document.createSection('Negative Annotations')
+notesSection.createParagraph(
+Entities with errors and warnings.)
+
+ncount=0
+for module in gumpSet.getModuleSequence():
+if not gumpSet.inModuleSequence(module): continue
+
+moduleSection=document.createSection('Module : ' + module.getName())
+
+# Link to the module
+self.insertLink(module,workspace,moduleSection.createParagraph())
+
+if not module.containsNasties():
+
+# Display the annotations
+self.documentAnnotations(moduleSection,project,1)
+
+for project in module.getProjects():
+if not gumpSet.inProjectSequence(project): continue
+if not project.containsNasties(): continue
+
+projectSection=moduleSection.createSection('Project : ' +
project.getName())
+
+# Link to the project
+self.insertLink(project,workspace,projectSection.createParagraph())
+
+# Display the annotations
+self.documentAnnotations(projectSection,project,1)
+
+ncount+=1
+
+if not ncount: notesTable.createLine('None')
+
+document.serialize()
#
# --
@@ -1540,14 +1585,14 @@
return totalDeps
-def documentAnnotations(self,xdocNode,annotatable):
+def documentAnnotations(self,xdocNode,annotatable,noWarn=0):
annotations=annotatable.getAnnotations()
if not annotations: return
annotationsSection=xdocNode.createSection('Annotations')
-if annotatable.containsNasties():
+if annotatable.containsNasties() and not noWarn:
annotationsSection.createWarning(\
'Some warnings and/or errors are present within these annotations.')
1.22 +1 -0 gump/template/forrest/src/documentation/content/xdocs/site.xml
Index: site.xml
===
RCS file: /home/cvs/gump/template/forrest/src/documentation/content/xdocs/site.xml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- site.xml 12 Mar 2004 16:10:39 - 1.21
+++ site.xml 24 Mar 2004 15:51:42 - 1.22
@@ -11,6 +11,7 @@
work label=Gump
index label=Workspace href=index.html/
index label=Build Log href=buildLog.html/
+index label=Notes Log href=notesLog.html/
/work
work label=Projects tab=home
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Adam Jack wrote: Adam, I think we should get rid of FoG entirely until we have a better solution. It is causing more harm than good. What is harm and what is refining discussion? If we remove it, what incentive do folks have to contribute improvements? The only incentive I see is an escalation of people that will tune the FoG metric so that their project show up on top. A measure, believe it or not, is a thing that introduces scarcity and anything that is scarce will trigger desires of possession from some people. I'll do whatever the group determines, but first teach me OSS 101 on such matters, please. Is this too bad to tolerate, or just bad enough to entice? It is not bad, it's just asking for trouble. We should design Gump keeping in mind that it should be silly to infer any judgement of quality out of the data. Our goal is not to measure, it's to help out the development process. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Gump-Check task
Leo Simons wrote: Maybe we could have an ant task that talks to the gump repository to keep (nay, improve on) that functionality. project default=test target name=verify-gump depends=build gump-check project=cocoon/ /target target name=test depends=build,verify-gump /target /project the gump-check task would get a list of requirements from the gump server (ie, what jars should exist, what directories, licenses, ...) and compare that info to the filesystem. It would warn the user of any errors. Like Ozzie, I'm just a dreamer ;) Let's keep dreaming. Gump looks closer to any port-like system that is out there for java stuff. We happen to have a huge amount of metadata and the automatic ability to make sure it remains in synch with it. it would *NOT* take much to do what leo is suggesting and solve the jar distribution thing. worth thinking about! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: fog factor
Stefano Mazzocchi wrote: We should design Gump keeping in mind that it should be silly to infer any judgement of quality out of the data. Our goal is not to measure, it's to help out the development process. Some people argue you can't improve what you can't measure. The counter point is whatever you measure you will improve, so make sure you measure the right thing. R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fog factor
Stefano Mazzocchi wrote: FoG stands for Friend of Gump, not for fog as in the white stuff suspended in the air that doesn't allow you to see thru. What about a NGAD factor? Stephen. -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] href considered harmful
Stefan Bodewig wrote: On Wed, 24 Mar 2004, Leo Simons [EMAIL PROTECTED] wrote: No webapp would enable anybody to put a different license on the descriptor, for whatever reason he/she should choose to do so. do you really think that will actually become an issue? Not really. There may be the issue of ownership, though. I don't want anybody to modify *my* descriptor. Not in the domts case, but it could become an issue and maybe even is today. well, that's an attitude I don't like! The gump (and wider open source) community owns gump, and that includes its descriptors. Participating in gump is participating in that community, according to our rules. agreed? Do you think Curt Arnold would object to moving the descriptor, for example? I asked him where he wanted to put it. Since Curt is no Apache committer but wanted to be able to maintain it, he decided to put it on the W3C box. which is a good reason. Once we agree on the basic principles we can figure out how to make the technology support that :D -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jrefactory.xml
antoine 2004/03/24 12:55:55 Modified:project jrefactory.xml Log: improving a little bit the descriptor, thanks to the remarks of Stefan Revision ChangesPath 1.17 +8 -5 gump/project/jrefactory.xml Index: jrefactory.xml === RCS file: /home/cvs/gump/project/jrefactory.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- jrefactory.xml23 Mar 2004 20:55:05 - 1.16 +++ jrefactory.xml24 Mar 2004 20:55:55 - 1.17 @@ -23,7 +23,11 @@ cvs repository=sourceforge host-prefix=cvs.JRefactory dir=jrefactory module=JRefactory/ - + project name=jai +jar name=jar/jai_codec.jar/ +jar name=jar/jai_core.jar/ + /project + project name=jrefactory packageorg.acm.seguin/package @@ -33,27 +37,26 @@ depend project=jaxen/ depend project=junit/ depend project=dom4j/ +depend project=jai/ +depend project=jakarta-bcel/ depend project=javacc/ +depend project=saxpath/ option project=jrefactory-prettynoclasspath//option work nested=ant.build/classes/ work nested=test/classes/ work nested=jar/ErrorList.jar/ work nested=jar/ProjectViewer.jar/ -work nested=jar/bcel.jar/ work nested=jar/collect.jar/ work nested=jar/core.jar/ work nested=jar/coreplugin.jar/ work nested=jar/findbugs.jar/ work nested=jar/findbugsGUI.jar/ work nested=jar/gjc-rt.jar/ -work nested=jar/jai_codec.jar/ -work nested=jar/jai_core.jar/ work nested=jar/jbuilder.jar/ work nested=jar/jedit.jar/ work nested=jar/openide.jar/ work nested=jar/primetime.jar/ work nested=jar/proguard.jar/ -work nested=jar/saxpath-1.0-fcs.jar/ jar name=ant.build/lib/jrefactory.jar/ /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RT] My personal roadmap for gump
Hi gang, I think it'd be nice to know what everyone's up to. I know some of the plans of some people and guess at the plans of others, but I'm sure many people are unaware of each others plans...anyway, here's my rather vague roadmap, and some context for that. This'll be a non-edited rant. I've got three projects I'm working on at the moment: * Jicarilla (java) * Gump (python) * Moin wiki @ apache (python) I know a lot about java, a little about python and a little about ruby (which, I have to say, is my fav. language atm by far). I plan to learn more about scripting languages, and how to build big projects using them. Lately, I've reallly been interested in glue. Jicarilla is mainly glue between components (and a fledgling webserver), gump is mainly glue between projects, wikis are mainly glue between communities that may not neccessarily be project-oriented. The glue between system-level tools, shell languages, scripting languages and generic languages (ie java) is quite different from the glue between projects and communities, and especially their overlap interests me (how gluing projects together seems to work well using a gluey piece of software, and how gluey pieces of software have rather unique communities). I don't make money from software nor do I plan to. I do this thing as a hobby, for the fun of it. I like talking, thinking, writing, and am somewhat addicted to bugfixing (no idea why I like it. Really don't). I plan to explore gump in order to learn python, and to improve on my software-user-interaction design abilities (since gump interacts rather badly with some users, there's lots of oppurtunity here). I am interested in how a glue project as gump can gradually evolve into a platform for glue. I plan to pour a lot of my ideas about collaborative distributed software development into or on top of gump. I see gump as about the most interesting (OSS community-wise) piece of software that exists, there's this vibe around here that I want to surf on. I really have /no/ time for /any/ of this. I spend a lot of time studying physics, and I should be spending more. And I have a real life of course. So I'm likely to have ideas, write e-mails (did I say I like talking?), then getting started on something, and abandoning it halfway through completion. I am always hoping that people pick up on an idea and run with it. When that happens, I'm usually enticed to actually finish some things. Not because I like finishing things, but because I like happy people :D This positive vibe, which I think gump has a lot of and will have a lot more of, is something I enjoyed tremendously when I joined the ranks of the ASF, but have been missing sometimes lately. I hope to bathe in it here :D A little more concretely, I'd like to think a lot more about gump workflow (the role of continuous integration in distributed open source development, and what that role should/could evolve to), talk about it a lot, and then prove the ideas that rolll out. I'm currently reading the 8-year-old Apple Mac user interface guidelines :D While doing that, I'd like to explore the rest of the workflow in OSS development whilst working on gump itself. For example, I think some of the parts of the ASF that I've seen are too closed and isolated and I'd like to explore with gump some of the ideas on how that can be done differently. An experiment in an experiment if you will. Yada yada yada. Could go on for a while, but I won't. Let's hear about you! :-D -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jrefactory.xml
Stefan, thanks for your comments, I have just checked in what you have suggested. collect.jar in jrefactory is not common-collections from apache (judging by the package names java.lang. ... ) It looks like something coming from Sun, and having to do with reflection or something like that, I am not sure what it exactly is. Cheers, Antoine Stefan Bodewig wrote: On 23 Mar 2004, [EMAIL PROTECTED] wrote: +work nested=jar/ErrorList.jar/ +work nested=jar/ProjectViewer.jar/ +work nested=jar/bcel.jar/ +work nested=jar/collect.jar/ +work nested=jar/core.jar/ +work nested=jar/coreplugin.jar/ +work nested=jar/findbugs.jar/ +work nested=jar/findbugsGUI.jar/ +work nested=jar/gjc-rt.jar/ +work nested=jar/jai_codec.jar/ +work nested=jar/jai_core.jar/ +work nested=jar/jbuilder.jar/ +work nested=jar/jedit.jar/ +work nested=jar/openide.jar/ +work nested=jar/primetime.jar/ +work nested=jar/proguard.jar/ +work nested=jar/saxpath-1.0-fcs.jar/ ugly. Any idea what the contents are? bcel.jar sounds like jakarta-bcel, collect could be commons-collections. JAI could be an installed package if other projects need it as well. saxpath is already somewhere as an installed package. In general I'd rather use a technique like project name=jai jar name=jar/jai_codec.jar/ jar name=jar/jai_core.jar/ /project inside the module combined with depend project=jai/ in the project for jars in CVS. This enables us to switch between using a jar from CVS, using an installed package and building a project from scratch more easily. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump-Check task
Isn't LocalCheck (the java Gump) already doing (at least locally on the gump box), but this should be extendable to do remotely. But I guess you were discussing Gumpy :). Mvgr, Martin On Wed, 2004-03-24 at 18:12, Stefano Mazzocchi wrote: Leo Simons wrote: Maybe we could have an ant task that talks to the gump repository to keep (nay, improve on) that functionality. project default=test target name=verify-gump depends=build gump-check project=cocoon/ /target target name=test depends=build,verify-gump /target /project the gump-check task would get a list of requirements from the gump server (ie, what jars should exist, what directories, licenses, ...) and compare that info to the filesystem. It would warn the user of any errors. Like Ozzie, I'm just a dreamer ;) Let's keep dreaming. Gump looks closer to any port-like system that is out there for java stuff. We happen to have a huge amount of metadata and the automatic ability to make sure it remains in synch with it. it would *NOT* take much to do what leo is suggesting and solve the jar distribution thing. worth thinking about! -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] My personal roadmap for gump
Leo Simons wrote: Yada yada yada. Could go on for a while, but I won't. Let's hear about you! :-D Thanks Leo, this is a wonderful idea. Here is my personal roadmap. I'm interested in data emergence: how you can make people create metadata without knowing and without feeling like they are paying a tax in doing so. Gump, to me, represents a way to create extremely high quality metadata about project development that would be tremendously complex/expensive for machines to do as a byproduct of applying the right amount of social pressure. I'm lucky enough to be paid to do what I would do anyway and I plan to get involved directly with gump in a really short period, as soon as the infrastructure of our project that I'm building start to become more solid. I personally think that bottom-up data emergence is the only way for the semantic web to come into existance: the top-down ontological might work in ivory towers but will never work in real life. What this means in concrete, well, I still don't know, but I have the gut feeling that the dynamics around Gump will be extremely beneficial for what we are trying to achieve in a more global scale. As well as it will be extremely beneficial as a across-programming-language-borders community unification tool. I think Gump has *tremendous* potentials. I plan to explore and research them in full details. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
[jira] Work Stopped: (GUMP-29) new user howto
Message: Work on this issue has been stopped by Leo Simons (mailto:[EMAIL PROTECTED]) - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-29 Here is an overview of the issue: - Key: GUMP-29 Summary: new user howto Type: Improvement Status: Open Priority: Major Project: Gump Fix Fors: unspecified Versions: unspecified Assignee: Leo Simons Reporter: Leo Simons Created: Sun, 14 Mar 2004 12:02 PM Updated: Wed, 24 Mar 2004 9:56 PM Description: New users seem weary of editing gump descriptors (especially when they don't live in their own cvs module but they have to change things in the gump repository), and most of them are very sketchy as to the steps one takes to fix things. Niclas Hedhman' recent experience in getting some of avalon to build using gump and the talk resulting from it on avalon-dev and gump-general are a good example of a new user we need to talk through things. We need a howto. Not just the technical explanation, but some philosophy (Everyone is free to work on gump. Everyone. Stuff like that) intertwined. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-39) gump-check ant task
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-39 Here is an overview of the issue: - Key: GUMP-39 Summary: gump-check ant task Type: New Feature Status: Unassigned Priority: Major Project: Gump Components: Python Fix Fors: unspecified Versions: unspecified Assignee: Reporter: Leo Simons Created: Wed, 24 Mar 2004 10:22 PM Updated: Wed, 24 Mar 2004 10:22 PM Description: You want the ability to verify a project state is consistent with what gump expects it to be after a build, but only gump can verify that. Maybe we could have an ant task that talks to the gump repository to keep (nay, improve on) that functionality. project default=test target name=verify-gump depends=build gump-check project=cocoon/ /target target name=test depends=build,verify-gump /target /project the gump-check task would get a list of requirements from the gump server (ie, what jars should exist, what directories, licenses, ...) and compare that info to the filesystem. It would warn the user of any errors. Mailing list thread @ http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=682505 - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
manual failure notifications...
Thumbs up to Antoine (and everyone else of course ;)) for all those manual failure notifications sent out to projects! I'm really interested to see how much of an effect this kind of thing has on the state of the tree. It seems to be a lot...be sure to blog about it :D -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project xml-xerces2.xml
mrglavas2004/03/24 20:44:59 Modified:project xml-xerces2.xml Log: Changes to Xerces2 descriptor: - xmlParserAPIs.jar - xml-apis.jar - this is the preferred name; xmlParserAPIs.jar has been deprecated - LICENSE - java/LICENSE - point to 2.0 license - Adding XML Schema API to javadoc. Revision ChangesPath 1.31 +4 -3 gump/project/xml-xerces2.xml Index: xml-xerces2.xml === RCS file: /home/cvs/gump/project/xml-xerces2.xml,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- xml-xerces2.xml 27 Feb 2004 09:22:57 - 1.30 +++ xml-xerces2.xml 25 Mar 2004 04:44:58 - 1.31 @@ -33,10 +33,10 @@ depend project=bootstrap-ant/ depend project=xjavac/ home nested=java/build/ -jar name=xercesImpl.jar id=parser type=boot/ -jar name=xmlParserAPIs.jar id=apis type=boot/ +jar name=xercesImpl.jar id=parser type=boot/ +jar name=xml-apis.jar id=apis type=boot/ -license name=LICENSE/ +license name=java/LICENSE/ nag from=Sam Ruby lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED]/ @@ -58,6 +58,7 @@ javadoc nested=java/build/docs/javadocs project=xml-xerces2 description dir=apiXML Standard API/description description dir=xniXerces Native Interface/description + description dir=xsXML Schema API/description description dir=xerces2Xerces2 Implementation/description description dir=otherOther Classes/description /javadoc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-40) non-committers can modify (some) descriptors
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-40 Here is an overview of the issue: - Key: GUMP-40 Summary: non-committers can modify (some) descriptors Type: Wish Status: Unassigned Priority: Major Project: Gump Components: Object Model (GOM) Fix Fors: unspecified Versions: unspecified Assignee: Reporter: Leo Simons Created: Wed, 24 Mar 2004 10:41 PM Updated: Wed, 24 Mar 2004 10:41 PM Description: It would be nice if people who are not committers @ the ASF have a way to modify descriptors, in particular developers of non-ASF projects maintaining the descriptors of those projects. This is currently done by putting those descriptors in a seperate cvs module and accessing them through ViewCVS, but this has several downsides as has been discussed here: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=681442 Possible alternatives could be a publicly writeable repository, an access-by-request repository, a web application with granular authaccess control, or all of the above. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (GUMP-41) stress-testing using gump on new ASF hardware
Message: A new issue has been created in JIRA. - View the issue: http://issues.apache.org/jira/secure/ViewIssue.jspa?key=GUMP-41 Here is an overview of the issue: - Key: GUMP-41 Summary: stress-testing using gump on new ASF hardware Type: Task Status: Unassigned Priority: Major Project: Gump Fix Fors: unspecified Versions: unspecified Assignee: Reporter: Leo Simons Created: Wed, 24 Mar 2004 10:45 PM Updated: Wed, 24 Mar 2004 10:45 PM Environment: linux, freebsd Description: Apache will be stresstesting some new machines using gump. One of them will keep running gump (probably on linux, but that's what the test is for), others will be reassigned. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depend in ant broken
Stefan Bodewig wrote: it looks as if Adam has changed something that has broken the depend tag. Instead of patching all descriptors that use it - quite a few - I'd rather roll back the change. Even if that means that some cactus builds will remain broken for a while. Does anybody have a Python Gump installation and could quickly try to revert the files in python/gump/model/ to something before 2003-04-18, in particular, I'd like you to try to just revert ant.py, depend.py and project.py (patch appended). Please run integrate.py on Struts or Tomcat-4. If that builds OK, we have gone back to a more stable state. Has this been fixed? If not, add to jira. Stefan, remember you have access to a Python Gump installation on lsd :D -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
Stefan Bodewig wrote: [EMAIL PROTECTED]: mx4j/mx4j-tools-from-packaged-jetty failed The top item on my TODO list. A real API compatibility problem between mx4j and Axis. hehehe. It's high on mine too...I need jetty to build :D Another random thought: it would be nice to be able to annotate parts of the build tree with comments like this. As in being able to attach a comment to the failure state of mx4j/mx4j-tools-from-packaged-jetty. With comments CCed to the mailing list of course :D -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project checkstyle.xml depot.xml
bodewig 2004/03/24 23:26:45 Modified:project checkstyle.xml depot.xml Log: Test cases need to be on the classpath Revision ChangesPath 1.25 +1 -1 gump/project/checkstyle.xml Index: checkstyle.xml === RCS file: /home/cvs/gump/project/checkstyle.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- checkstyle.xml24 Mar 2004 08:10:38 - 1.24 +++ checkstyle.xml25 Mar 2004 07:26:45 - 1.25 @@ -69,7 +69,6 @@ project name=checkstyle-test packagecom.puppycrawl.tools.checkstyle/package -mkdir dir=target/checkstyle/ ant target=gump.setup run.tests property name=version value=@@DATE@@/ /ant @@ -80,6 +79,7 @@ depend project=junit/ work nested=target/checkstyle/ +work nested=target/tests/ nag from=Conor MacNeill lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED]/ 1.16 +1 -0 gump/project/depot.xml Index: depot.xml === RCS file: /home/cvs/gump/project/depot.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- depot.xml 23 Mar 2004 06:43:57 - 1.15 +++ depot.xml 25 Mar 2004 07:26:45 - 1.16 @@ -85,6 +85,7 @@ depend project=jakarta-regexp/ depend project=commons-httpclient/ depend project=commons-vfs/ +depend project=xml-xerces/ jar name=jars/apache-depot-update-@@DATE@@.jar/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project depot.xml
bodewig 2004/03/24 23:27:30 Modified:project depot.xml Log: depot-update-test needs Xerces Revision ChangesPath 1.17 +1 -1 gump/project/depot.xml Index: depot.xml === RCS file: /home/cvs/gump/project/depot.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- depot.xml 25 Mar 2004 07:26:45 - 1.16 +++ depot.xml 25 Mar 2004 07:27:30 - 1.17 @@ -85,7 +85,6 @@ depend project=jakarta-regexp/ depend project=commons-httpclient/ depend project=commons-vfs/ -depend project=xml-xerces/ jar name=jars/apache-depot-update-@@DATE@@.jar/ @@ -111,6 +110,7 @@ depend project=depot-update inherit=all/ depend project=ant-testutil/ depend project=junit/ +depend project=xml-xerces/ ant basedir=update buildfile=build.xml target=test vm=1.4 property name=ant.home project=ant reference=home / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Thu, 25 Mar 2004, Leo Simons [EMAIL PROTECTED] wrote: hehehe. It's high on mine too...I need jetty to build :D You can fall back to the packaged jetty for the time being. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: depend in ant broken
On Thu, 25 Mar 2004, Leo Simons [EMAIL PROTECTED] wrote: Has this been fixed? Yes. Stefan, remember you have access to a Python Gump installation on lsd :D Yeah, I know. But I'd have to find my way around to see where the actual Python code that is used to run lives and setup the correct environment for my account and ... Cheers Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Wed, 24 Mar 2004, Stefan Bodewig [EMAIL PROTECTED] wrote: Tapestry is a problem in itself, since the Gump descriptor is inside the tapestry module. A manual nag together with a patch to the descriptor may help. Number two on my TODO list, helping hands welcome 8-) Actually it is number three since jelly-tags-ant is holding up a lot and it may even be a backwards compatibility problem in Ant. I may try using the 1.5 branch of Ant to see whether it works there. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] href considered harmful
On Wed, 24 Mar 2004, Leo Simons [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: There may be the issue of ownership, though. I don't want anybody to modify *my* descriptor. Not in the domts case, but it could become an issue and maybe even is today. well, that's an attitude I don't like! Neither do I, but let's be realistic. Even inside some Apache projects you have places with this is my code/project - ask before you touch anything attitudes. The gump (and wider open source) community owns gump, and that includes its descriptors. Participating in gump is participating in that community, according to our rules. agreed? Say Gump builds project A since it depends on many Apache projects and is used by many Apache projects. Do you prefer to take care of a descriptor for it not knowing anything about A or to let the people behind A maintain it? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant and Xerces
Hi, the whole Ant needs an XML parser business currently is quite complex and I think it doesn't have to be. If your project depends on ant and not on xml-apis, then you don't need to specify an XML parser and get the one of your JDK - assuming you use JDK 1.4+ but we assume that in many places anyway. If, on the other hand, your project depends on xml-apis, even in an inherited way that may be unobvious - I still don't know why depot-update-test depends on xml-apis when depot-update doesn't - you'll have to use Xerces since that is the default parser configured in SAXParserFactory. So why is Xerces not a runtime dependency of Ant? bootstrap-ant depends on jaxp so that we can start with a minimal dependency. This combination then builds crimson. bootstrap-ant plus crimson build xerces. And finally bootstrap-ant plus xerces build ant. Right now I think we should make xml-apis and xml-xerces runtime dependencies of ant and dist-ant so that all projects that depend on ant and set inherit=runtime have a fully functional Ant. This shouldn't break anything and if you really want a different parser you can omit inherit=runtime on the dependency. Do you think I am missing something? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
