cvs commit: gump/python test.html
ajack 2004/06/14 19:42:28 Removed: python Tag: CleanUp test.html Log: EOD commit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/template/xhtml/css - New directory
ajack 2004/06/14 19:42:26 gump/template/xhtml/css - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/gump/stats statsdb.py
ajack 2004/06/14 14:31:47 Modified:python/gump/test Tag: CleanUp __init__.py notifying.py utils.py pyunit.py model.py python/gump/runner Tag: CleanUp runner.py tasks.py python/gump/utils Tag: CleanUp launcher.py timing.py tasks.py work.py __init__.py python/gump/core Tag: CleanUp gumprun.py actor.py python/gump/notify Tag: CleanUp notifier.py notification.py python Tag: CleanUp .cvsignore python/gump/document/xdocs Tag: CleanUp resolver.py documenter.py xdoc.py python/gump/model Tag: CleanUp workspace.py project.py depend.py python/gump/admin Tag: CleanUp stats.py python/gump/update Tag: CleanUp artifact.py python/gump Tag: CleanUp check.py python/gump/loader Tag: CleanUp loader.py python/gump/integration Tag: CleanUp depot.py python/gump/stats Tag: CleanUp statsdb.py Added: template/xhtml/gump_icons Tag: CleanUp failed.png complete.png prerequisite_failed.png no_work_performed.png unset.png success.png python/gump/test Tag: CleanUp timing.py xdocs.py python Tag: CleanUp test.html python/gump/document/xdocs Tag: CleanUp config.py Removed: python/gump/test Tag: CleanUp xdoc_tests.py Log: Work on optional XHTML support. Revision ChangesPath No revision No revision 1.1.2.1 +11 -0 gump/template/xhtml/gump_icons/Attic/failed.png <> 1.1.2.1 +12 -0 gump/template/xhtml/gump_icons/Attic/complete.png <> 1.1.2.1 +9 -0 gump/template/xhtml/gump_icons/Attic/prerequisite_failed.png <> 1.1.2.1 +8 -0 gump/template/xhtml/gump_icons/Attic/no_work_performed.png <> 1.1.2.1 +8 -0 gump/template/xhtml/gump_icons/Attic/unset.png <> 1.1.2.1 +10 -0 gump/template/xhtml/gump_icons/Attic/success.png <> No revision No revision 1.12.2.2 +1 -1 gump/python/gump/test/__init__.py http://cvs.apache.org/viewcvs/gump/python/gump/test/__init__.py.diff?r1=1.12.2.1&r2=1.12.2.2 1.3.2.3 +1 -4 gump/python/gump/test/notifying.py http://cvs.apache.org/viewcvs/gump/python/gump/test/notifying.py.diff?r1=1.3.2.2&r2=1.3.2.3 1.13.2.1 +1 -47 gump/python/gump/test/utils.py http://cvs.apache.org/viewcvs/gump/python/gump/test/utils.py.diff?r1=1.13&r2=1.13.2.1 1.32.2.3 +15 -3 gump/python/gump/test/pyunit.py http://cvs.apache.org/viewcvs/gump/python/gump/test/pyunit.py.diff?r1=1.32.2.2&r2=1.32.2.3 1.21.2.3 +7 -3 gump/python/gump/test/model.py http://cvs.apache.org/viewcvs/gump/python/gump/test/model.py.diff?r1=1.21.2.2&r2=1.21.2.3 No revision http://cvs.apache.org/viewcvs/gump/python/gump/test/model.py.diff?r1=1.21.2.2&r2=1.21.2.3 No revision http://cvs.apache.org/viewcvs/gump/python/gump/test/model.py.diff?r1=1.21.2.2&r2=1.21.2.3 1.1.2.1 +103 -0gump/python/gump/test/Attic/timing.py http://cvs.apache.org/viewcvs/gump/python/gump/test/Attic/timing.py.diff?r1=1.1&r2=1.1.2.1 1.1.2.1 +68 -0 gump/python/gump/test/Attic/xdocs.py http://cvs.apache.org/viewcvs/gump/python/gump/test/Attic/xdocs.py.diff?r1=1.1&r2=1.1.2.1 No revision No revision 1.5.2.3 +2 -1 gump/python/gump/runner/runner.py http://cvs.apache.org/viewcvs/gump/python/gump/runner/runner.py.diff?r1=1.5.2.2&r2=1.5.2.3 1.4.2.1 +1 -13 gump/python/gump/runner/tasks.py http://cvs.apache.org/viewcvs/gump/python/gump/runner/tasks.py.diff?r1=1.4&r2=1.4.2.1 No revision No revision 1.24.2.2 +3 -2 gump/python/gump/utils/launcher.py http://cvs.apache.org/viewcvs/gump/python/gump/utils/launcher.py.diff?r1=1.24.2.1&r2=1.24.2.2 1.1.2.2 +262 -39 gump/python/gump/utils/Attic/timing.py http://cvs.apache.org/viewcvs/gump/python/gump/utils/Attic/timing.py.diff?r1=1.1.2.1&r2=1.1.2.2 1.1.2.2 +7 -6 gump/python/gump/utils/Attic/tasks.py http://cvs.apache.org/viewcvs/gump/python/gump/utils/Attic/tasks.py.diff?r1=1.1.2.1&r2=1.1.2.2 1.15.4.4 +40 -24gump/python/gump/utils/work.py http://cvs.apache.org/viewcvs/gump/python/gump/utils/work.py.diff?r1=1.15.4.3&r2=1.15.4.4 1.44.2.4 +0 -114gump/python/gump/utils/__init__.py http://cvs.apache.org/viewcvs/gump/python/gump/utils/__init__.py.diff?r1=1.44.2.3&r2=1.44.2.4 No revision No revision 1
cvs commit: gump/template/xhtml/gump_icons - New directory
ajack 2004/06/14 14:26:38 gump/template/xhtml/gump_icons - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/template/xhtml - New directory
ajack 2004/06/14 14:26:38 gump/template/xhtml - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Deprecation
I'd like to discuss deprecation. The only Gump API we have today is the metadata. I'd like to formalize that [perhaps even with version attributes on major (distributed/community edited) elements], have XSD schema for validation. I'd also like to be able to migrate/enhance it it. (I've stored up numerous many metadata changes/extension I've not put in 'cos of Traditional.) That said we have environment/usage (functionality) deprecations that could impact users. Two I'd like to perform (either as deprecations or out-and-out removals): 1) The use of 'pgrep' [unless we can figure out process groups]. 2) The use of 'forrest *batch call*' [the forrest folks have deprecated the interface we rely upon for this, and with batch & xdocs (forrest webapp) we have convoluted code.] (BTW: I'm not ready to be able to generate HTML raw, w/o forrest doing the cooking, although I'd like to get there one day.) I'd like to be able to deprecate functionality. Since we don't have releases (we work from CVS HEAD), I'd consider tagging the tree (so folks can freeze themselves at a certain point). Unfortunately this'll freeze the metadata, so doesn't seem too workable. So, what do folks think? How ought we proceed? regards, Adam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump compatible ant tasks and data types
On Monday 14 June 2004 20:33, Stephen McConnell wrote: > WDYT? I think you are in too deep water for me... Maybe someone else swims better. To me Gump could be copying the dependent Jars into a known temporary location, and has X number of BASH commands defined to execute, in which the classloading / other arguments are constructed. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/gump/model object.py
ajack 2004/06/14 06:38:04
Modified:python/gump/model Tag: CleanUp object.py
Log:
Support variable (i.e. @@DATE@@) expansion.
Revision ChangesPath
No revision
No revision
1.24.2.5 +18 -2 gump/python/gump/model/object.py
Index: object.py
===
RCS file: /home/cvs/gump/python/gump/model/object.py,v
retrieving revision 1.24.2.4
retrieving revision 1.24.2.5
diff -u -r1.24.2.4 -r1.24.2.5
--- object.py 11 Jun 2004 17:09:50 - 1.24.2.4
+++ object.py 14 Jun 2004 13:38:04 - 1.24.2.5
@@ -33,6 +33,7 @@
from gump.model.propagation import *
class ModelObject(Annotatable,Workable,FileHolder,Propogatable,Ownable):
+
"""Base model object for a single entity"""
def __init__(self,dom,owner=None):
@@ -122,7 +123,21 @@
return False
def getDomAttributeValue(self,name,default=None):
-return getDomAttributeValue(self.element,name,default)
+return self.expandVariables(
+getDomAttributeValue(self.element,name,default))
+
+def expandVariables(self,value):
+"""
+
+Return a copy of the value with any Gump
+variables expanded.
+
+"""
+if not value: return value
+
+# Right now just one supported
+return value.replace('@@DATE@@',default.date)
+
def hasDomChild(self,name):
if hasDomChild(self.element,name): return True
@@ -132,7 +147,8 @@
return getDomChild(self.element,name)
def getDomChildValue(self,name,default=None):
-return getDomChildValue(self.element,name,default)
+return self.expandVariables(
+getDomChildValue(self.element,name,default))
def getDomChildIterator(self,name):
return getDomChildIterator(self.element,name)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-commons-codec-11.xml
ajack 2004/06/14 06:14:29 Modified:profile gump.xml project jakarta-commons-codec-11.xml Log: Try to mark this project as a package. Revision ChangesPath 1.352 +1 -0 gump/profile/gump.xml Index: gump.xml === RCS file: /home/cvs/gump/profile/gump.xml,v retrieving revision 1.351 retrieving revision 1.352 diff -u -r1.351 -r1.352 --- gump.xml 4 Jun 2004 04:22:25 - 1.351 +++ gump.xml 14 Jun 2004 13:14:29 - 1.352 @@ -275,6 +275,7 @@ + 1.5 +1 -1 gump/project/jakarta-commons-codec-11.xml Index: jakarta-commons-codec-11.xml === RCS file: /home/cvs/gump/project/jakarta-commons-codec-11.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- jakarta-commons-codec-11.xml 11 Jun 2004 14:38:19 - 1.4 +++ jakarta-commons-codec-11.xml 14 Jun 2004 13:14:29 - 1.5 @@ -21,7 +21,7 @@ Jakarta Commons Codec 1.1 - + org.apache.commons.codec Commons Encoding/Decoding Package http://jakarta.apache.org/commons/codec/"/> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project xml-xmlbeans.xml
bodewig 2004/06/14 05:40:31 Modified:project xml-xmlbeans.xml Log: new xmlbeans dependenciy on jaxen Revision ChangesPath 1.8 +1 -0 gump/project/xml-xmlbeans.xml Index: xml-xmlbeans.xml === RCS file: /home/cvs/gump/project/xml-xmlbeans.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- xml-xmlbeans.xml 27 Feb 2004 09:22:57 - 1.7 +++ xml-xmlbeans.xml 14 Jun 2004 12:40:31 - 1.8 @@ -27,6 +27,7 @@ + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project dom4j.xml
bodewig 2004/06/14 05:35:32 Modified:project dom4j.xml Log: new dom4j dependencies Revision ChangesPath 1.36 +2 -0 gump/project/dom4j.xml Index: dom4j.xml === RCS file: /home/cvs/gump/project/dom4j.xml,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- dom4j.xml 6 May 2004 16:03:40 - 1.35 +++ dom4j.xml 14 Jun 2004 12:35:32 - 1.36 @@ -43,6 +43,8 @@ + + - 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 Monday 14 June 2004 08:15, Stephen McConnell wrote: So - the questions is ... is there a nice small gump API I can build against that would enable the possibility for a totally integrated solution? Gump is in Python, and I haven't heard of any Java->Gump binding... If so, what more precisely do you expect? Without a mechanism to construct paths resolved via gump (or a gump environment and set of rules), you have to construct gump descriptors for each potential classloading scenario. I.e. a gump file for building, another gump file for generating plugin descriptions, a third gump file to run tests. Clearly a manually maintained set of gump files would be impractical which led to the thinking concerning either (a) automated gump file generation, or (b) gump integration within ant types and tasks. I'm of the opinion that integration would be a much better way to go. So - the question is - how to achieve this? Taking a non-api approach ... Gump is creating artifacts along the lines of the following: [root] == /usr/local/gump/public/workspace [module] == avalon [project] == avalon-util-i18n [output-jar] == target/avalon-util-i18n-[datestamp].jar If I understand correctly, Gump then copies the file referenced by [output-jar] to a repository: [cache]/[module]/jars/avalon-util-i18n-20040613.jar With the single exception of [module] handling, this the same as the cache structure used in maven, avalon-repository and the the build tasks I'm using. In effect it seems to me that we are really close to being able to provide a model where gump delegates classpath management to a build container if the the above could be represented as: [cache]/[group]/jars/avalon-util-i18n-20040613.jar Keeping in mind that I'm thinking while witting - it seems to me that if we could construct the [group] based on either a declaration in a gump file (e.g. a project level group id), or possibly via nested [mudules] (e.g. /[avalon]/[util] ) - then a build system launched by gump could do gump artifact resolution and subsequent publication from/to a gump repository using the following two input parameters * [cache] directory * [datestamp] (and possibly a list of project id to group id mappings where a standard convention is not used) WDYT? Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
