cvs commit: gump/project ant.xml
bodewig 2004/06/21 00:35:21 Modified:project ant.xml Log: change nag address Revision ChangesPath 1.21 +7 -7 gump/project/ant.xml Index: ant.xml === RCS file: /home/cvs/gump/project/ant.xml,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- ant.xml 21 Jun 2004 06:53:28 - 1.20 +++ ant.xml 21 Jun 2004 07:35:21 - 1.21 @@ -55,7 +55,7 @@ license name=LICENSE/ -nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; +nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED]/ /project @@ -109,7 +109,7 @@ javadoc nested=build/javadocs project=ant/ -nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; +nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED]/ /project @@ -124,7 +124,7 @@ home nested=build/lib/ jar name=ant-testutil.jar id=ant-testutil/ -nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; +nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED]/ /project @@ -144,7 +144,7 @@ work nested=src/testcases/ work nested=src/etc/testcases/ -nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; +nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED] subject=Test Failure - Ant/ /project @@ -158,7 +158,7 @@ jar name=lib/ant.jar/ jar name=lib/ant-launcher.jar id=ant-launcher/ -nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; +nag from=Gump Integration Build lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED] subject=Bootstrap Failure - Ant regexp pattern=/error// @@ -187,7 +187,7 @@ jar name=optional-dynprop.jar id=embed-optional/ nag to=[EMAIL PROTECTED] - from=Nicola Ken Barozzi lt;[EMAIL PROTECTED]gt;/ + from=Gump Integration Build lt;[EMAIL PROTECTED]gt;/ /project project name=ant-xdocs-proposal @@ -202,7 +202,7 @@ depend project=xjavadoc/ depend project=jakarta-velocity-dvsl inherit=runtime/ nag to=[EMAIL PROTECTED] - from=Erik Hatcher lt;[EMAIL PROTECTED]gt;/ + from=Gump Integration Build lt;[EMAIL PROTECTED]gt;/ work nested=proposal/xdocs/build/classes/ javadoc nested=proposal/xdocs/build/docs/manual project=Ant xdocs proposal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jakarta-jmeter.xml
On Mon, 2004-06-21 at 08:44, Stefan Bodewig wrote: On 20 Jun 2004, [EMAIL PROTECTED] wrote: +work nested=lib/xpp3-1.1.3.4.D.jar/ xpp is available from the dom4j descriptor - I have no idea which one is more recent but IMHO we should stick with one. +work nested=lib/xstream-1.0.1.jar/ This could also be built from source. Don't know the criteria for that though.. Mvgr, martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jakarta-jmeter.xml
On Mon, 21 Jun 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: On Mon, 2004-06-21 at 08:44, Stefan Bodewig wrote: On 20 Jun 2004, [EMAIL PROTECTED] wrote: +work nested=lib/xpp3-1.1.3.4.D.jar/ xpp is available from the dom4j descriptor - I have no idea which one is more recent but IMHO we should stick with one. +work nested=lib/xstream-1.0.1.jar/ This could also be built from source. Don't know the criteria for that though.. If it is used by more than one project and easy to build from source (which includes doesn't break every second day) I'd be all for building. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jakarta-jmeter.xml
The project is mavenized and Joe isn't the type of guy to break things constantly... For now only one project is using it (although I thought maven2 uses it, but I must verify that) mvgr, Martin On Mon, 2004-06-21 at 11:22, Stefan Bodewig wrote: On Mon, 21 Jun 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: On Mon, 2004-06-21 at 08:44, Stefan Bodewig wrote: On 20 Jun 2004, [EMAIL PROTECTED] wrote: +work nested=lib/xpp3-1.1.3.4.D.jar/ xpp is available from the dom4j descriptor - I have no idea which one is more recent but IMHO we should stick with one. +work nested=lib/xstream-1.0.1.jar/ This could also be built from source. Don't know the criteria for that though.. If it is used by more than one project and easy to build from source (which includes doesn't break every second day) I'd be all for building. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: legalities of jar publishing (was: Re: [VOTE] retire java gump)
And what is the use of publishing jars that are built against the latest jars ? They will be useless in a real environment or even test environments and will probably not get any support from the project concerning. It simply is not a nightly build against the dependencies set by the project. Gump just points out to a project and it's dependencies when something bad is going to happen. It is looking ahead for us, where we programmers forgot to do that Log4J was a good example of this. So besides legal issues, I would never want a nightly build made by gump for my projects to be used by others, unless gump uses the exact versions for the dependencies I defined, but that defeats gumps main goal, as far as I am concerned. Mvgr, Martin On Mon, 2004-06-21 at 11:48, Leo Simons wrote: Disclaimer: IANAL. IIRC There is no board policy about redistribution of materials by gump. There is just concern, and the concern is not just with the board. The Gump PMC is supposed to be protecting the legal interests of the ASF wrt gump, and it is gump people who disabled jar distribution. I don't remember any of the details, but here's a few things I do know: * the ASF only wants to distribute software written and owned by the ASF * the ASF licenses all of its software under the apache license, and this must be true for all distributions published * distribution of software by the ASF projects should be done by PMCs or ASF officers, for legal protection * the ASF has high standards about releases. We want to provide things like MD5 files, gpg signatures, etc. Users need to trust that the things the ASF distributes are high-quality, and for that to be true, high quality must be consistent. * gump builds non-ASF-owned software under other licenses than the apache license * the gump pmc does not check the quality or validity of the outputs of gump, nor take an active approach to publishing those results * gump does not generate MD5 files, gpg signatures, etc From the above it should be clear that we're a bit reluctant about publishing the jars gump produces! People have put in work to alleviate these concerns (the license/ tag is one example of that), but I'm not sure where we're at right now. Sure, third parties are free to use gump and publish those jars, and they could do that using python gump. But that's not really what's happening right now. I think the only host who still publishes jars is covalent, and that is more like a shared hosting box that covalent loans to the gump team than a seperate entity. So that repository is likely going away, too. Python gump does generate the jar repository, and publishing it is a rather trivial task (see http://nagoya.apache.org/jira/browse/GUMP-67). The issue is not technical. cheers, - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: legalities of jar publishing
One of the questions that haven't really been answered/resolved by the board (IIRC) is whether automated snapshots are considered releases. If so, you can forget the whole business of nightly builds being distributed from ASF hardware - no matter whether they've been built by Gump or any other mechanism - since even those nightly builds would require active PMC approval. Each nightly build. On Mon, 21 Jun 2004, Leo Simons [EMAIL PROTECTED] wrote: Python gump does generate the jar repository, and publishing it is a rather trivial task (see http://nagoya.apache.org/jira/browse/GUMP-67). The issue is not technical. I agree. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: legalities of jar publishing
On Mon, 21 Jun 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: So besides legal issues, I would never want a nightly build made by gump for my projects to be used by others, unless gump uses the exact versions for the dependencies I defined, That's you. Ant used Gump to create nightly builds until Sam's machine broke down. So did Cactus and JMeter. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: legalities of jar publishing
As does commons: http://cvs.apache.org/builds/jakarta-commons/nightly/ S. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 June 2004 12:32 To: [EMAIL PROTECTED] Subject: Re: legalities of jar publishing On Mon, 21 Jun 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: So besides legal issues, I would never want a nightly build made by gump for my projects to be used by others, unless gump uses the exact versions for the dependencies I defined, That's you. Ant used Gump to create nightly builds until Sam's machine broke down. So did Cactus and JMeter. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: legalities of jar publishing
Commons nightlies uses the dependencies specified by the developers. (unless the script changed) Mvgr, Martin On Mon, 2004-06-21 at 13:46, BAZLEY, Sebastian wrote: As does commons: http://cvs.apache.org/builds/jakarta-commons/nightly/ S. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 June 2004 12:32 To: [EMAIL PROTECTED] Subject: Re: legalities of jar publishing On Mon, 21 Jun 2004, Martin van den Bemt [EMAIL PROTECTED] wrote: So besides legal issues, I would never want a nightly build made by gump for my projects to be used by others, unless gump uses the exact versions for the dependencies I defined, That's you. Ant used Gump to create nightly builds until Sam's machine broke down. So did Cactus and JMeter. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project dom4j.xml
ajack 2004/06/21 07:02:37 Modified:project dom4j.xml Log: Correction, in the xml sub-directory. Revision ChangesPath 1.40 +1 -1 gump/project/dom4j.xml Index: dom4j.xml === RCS file: /home/cvs/gump/project/dom4j.xml,v retrieving revision 1.39 retrieving revision 1.40 diff -u -r1.39 -r1.40 --- dom4j.xml 21 Jun 2004 13:37:34 - 1.39 +++ dom4j.xml 21 Jun 2004 14:02:37 - 1.40 @@ -46,7 +46,7 @@ depend project=xml-fop inherit=runtime/ depend project=jtidy/ depend project=junitperf/ -junitreport nested=build/test-results/ +junitreport nested=build/test-results/xml/ jar name=build/dom4j.jar id=dom4j/ license name=LICENSE.txt/ nag from=Maarten Coene lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED] / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: legalities of jar publishing
One of the questions that haven't really been answered/resolved by the board (IIRC) is whether automated snapshots are considered releases. This is really a big deal (for me probably others). If so, you can forget the whole business of nightly builds being distributed from ASF hardware - no matter whether they've been built by Gump or any other mechanism - since even those nightly builds would require active PMC approval. Each nightly build. Yup. That would be a lot of impact on developers/development. I sure hope not! But, I guess we need to bite the bullet and initiate a conversation (somewhere general, or with the board) on this matter. If we made it clear (in the jar name, in the manifest?) that these were nightly builds and not releases, I'd sure hope we could redistribute. On Mon, 21 Jun 2004, Leo Simons [EMAIL PROTECTED] wrote: Python gump does generate the jar repository, and publishing it is a rather trivial task (see http://nagoya.apache.org/jira/browse/GUMP-67). The issue is not technical. I agree. Oops, I missed this, I see you know. I assume it is being (and ought be) sat upon until we resolve the legality. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/python/gump/build builder.py
ajack 2004/06/21 08:53:31
Modified:template/xhtml/css Tag: CleanUp style.css
python/gump/model Tag: CleanUp propagation.py misc.py
python/gump/document/xdocs Tag: CleanUp xdoc.py
python/gump/loader Tag: CleanUp loader.py
python/gump/document Tag: CleanUp documenter.py
.Tag: CleanUp gumpytest.sh
python/gump/build Tag: CleanUp builder.py
Added: template/xhtml Tag: CleanUp favicon.ico
Removed: python/gump/model Tag: CleanUp rawmodel.py
Log:
Cosmetic tweaks (to XHTML/CSS).
i.e the sort of distraction I wanted to avoid by using XDOCS only. ;-)
Revision ChangesPath
No revision
No revision
1.1.2.4 +1 -1 gump/template/xhtml/css/Attic/style.css
Index: style.css
===
RCS file: /home/cvs/gump/template/xhtml/css/Attic/style.css,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- style.css 18 Jun 2004 14:58:16 - 1.1.2.3
+++ style.css 21 Jun 2004 15:53:30 - 1.1.2.4
@@ -1 +1 @@
-img { border: 0 }
HR { color: #8EB4D9; height: 1px; text-align: center; width: 90%; position:
relative }
# Annotations
.DEBUG { background-color: #00 }
.INFO { background-color: #00FF00 }
.WARN { background-color: #00 }
.ERROR { background-color: #FF }
# State
.SUCCESS{ background-color: #00FF00 }
.FAILED { background-color: #FF }
.PREREQFAILED { background-color: #00 }
\ No newline at end of file
+img { border: 0 }
HR { color: #8EB4D9; height: 1px; text-align: center; width: 90%; position:
relative }
TABLE.TRANSPARENT { border: none; width: 100% }
TABLE {border: thin solid #00; width: 100% }
# Annotations
.DEBUG { background-color: #00 }
.INFO { background-color: #99CC66 }
.WARN { background-color: #99 }
.ERROR { background-color: #CC }
# State
.SUCCESS{ background-color: #99CC66 }
.FAILED { background-color: #CC; foreground-color: #FF }
.PREREQFAILED { background-color: #99 }
.COMPLETE { background-color: #00CCFF }
.UNSET { background-color: #CC }
\ No newline at end of file
No revision
No revision
1.3.4.1 +1 -4 gump/python/gump/model/propagation.py
Index: propagation.py
===
RCS file: /home/cvs/gump/python/gump/model/propagation.py,v
retrieving revision 1.3
retrieving revision 1.3.4.1
diff -u -r1.3 -r1.3.4.1
--- propagation.py22 Apr 2004 22:58:16 - 1.3
+++ propagation.py21 Jun 2004 15:53:30 - 1.3.4.1
@@ -75,9 +75,6 @@
for object in self.getChildren():
object.changeState(state,reason,cause,message)
-def setCause(self,cause):
-if not self.cause: self.cause=cause
-
def hasCause(self):
return self.cause
@@ -85,7 +82,7 @@
return self.cause
def addCause(self,cause):
-if not self.cause: self.setCause(cause)
+if not self.cause: self.cause=cause
self.causes.append(cause)
def getCauses(self):
1.1.2.4 +55 -11gump/python/gump/model/Attic/misc.py
Index: misc.py
===
RCS file: /home/cvs/gump/python/gump/model/Attic/misc.py,v
retrieving revision 1.1.2.3
retrieving revision 1.1.2.4
diff -u -r1.1.2.3 -r1.1.2.4
--- misc.py 18 Jun 2004 14:58:17 - 1.1.2.3
+++ misc.py 21 Jun 2004 15:53:30 - 1.1.2.4
@@ -151,22 +151,66 @@
class JunitReport(Resolvable):
def __init__(self,dom,owner):
Resolvable.__init__(self,dom,owner)
-
-# represents a mkdir/ element
-class Mkdir(Resolvable):
-def __init__(self,dom,owner):
-Resolvable.__init__(self,dom,owner)
-
-# represents a delete/ element
-class Delete(Resolvable):
-def __init__(self,dom,owner):
-Resolvable.__init__(self,dom,owner)
-
+
+
# represents a work/ element
class Work(Resolvable):
def __init__(self,dom,owner):
Resolvable.__init__(self,dom,owner)
+
+
+class DirResolvable(ModelObject):
+
+ Common code for getting a directory (attribute) and
+ returning that as a path relative to the
+
+def
brutus gump (8080-80)
Can we please make gump output available at http://brutus.apache.org/gump/ws-axis/ws-axis-test/index.html instead of http://brutus.apache.org:8080/gump/ws-axis/ws-axis-test/index.html Thanks, dims -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jakarta-commons-sandbox.xml
Thanks!! [EMAIL PROTECTED] wrote: bodewig 2004/06/21 07:37:56 Modified:project jakarta-commons-sandbox.xml Log: Adapt jar name to the one generated by Maven Revision ChangesPath 1.163 +1 -2 gump/project/jakarta-commons-sandbox.xml Index: jakarta-commons-sandbox.xml === RCS file: /home/cvs/gump/project/jakarta-commons-sandbox.xml,v retrieving revision 1.162 retrieving revision 1.163 diff -u -r1.162 -r1.163 --- jakarta-commons-sandbox.xml 20 Jun 2004 09:19:24 - 1.162 +++ jakarta-commons-sandbox.xml 21 Jun 2004 14:37:55 - 1.163 @@ -62,10 +62,9 @@ depend project=junit / depend project=xml-xerces / -work nested=target/classes / home nested=compress/target / -jar name=compress/target/commons-compress-@@DATE@@.jar / +jar name=commons-compress-0.1-dev.jar / javadoc nested=target/docs/apidocs / - 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: commons-compress - Gump/Maven issues?
I don't know what extent you want to push back on the projects that gump builds, but it seems to me that they are either doing something that pushes maven beyond it's limits, or the decriptor might be out of date. I checked out jakarta-commons-sandbox/compress to investigate furthur, but I don't see this descriptor property you are talking about.. Could you enlightenme on this? Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, June 21, 2004 5:30 PM To: Gump code and data Subject: Re: commons-compress - Gump/Maven issues? On Monday 21 June 2004 22:47, Stefan Bodewig wrote: (1) The descriptor of commons-compress sets a property named component.version and hopes to get this into the jar name, which obviously doesn't work that way. Maven still uses /project/currentVersion from the POM. If no Maven guys are around... My wild guess would b to try to set pom.currentVersion property instead. Then it is a question if Maven overwrites it or not... (2) The work entry inside the descriptor pointed to nowhere and there is no work entry for the generated test classes, still the test goal manages to load the freshly compiled test classes. This means that we are not getting the effect of build.sysclasspath=only in Maven builds. The jar overrides will catch the artifacts Gump knows about but Maven will happily let the goals (plugins, tasks, I don't know the correct terms) add more stuff to the classpath itself. Sorry, this is beyond my knowledge, but hardly surprises me. For things like work directories for compiled classes this probably is good, but it may also lead to situations where Gump doesn't manage to substitute a jar from CVS with a freshly compiled one. Generally, Maven will happily download the required Jars from remote repositories, which normally can be disabled by running off-line mode (-o). However, what it builds today will be available in the local repository for use tomorrow, so I guess you are missing to nuke the local repository ( normally in $HOME/.maven/repository) Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - 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: brutus gump (8080-80)
Can we please make gump output available at http://brutus.apache.org/gump/ws-axis/ws-axis-test/index.html instead of http://brutus.apache.org:8080/gump/ws-axis/ws-axis-test/index.html I can but file the request, but the request is there: http://nagoya.apache.org/jira/browse/GUMP-59 regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
Eric Pugh wrote: I checked out jakarta-commons-sandbox/compress to investigate furthur, but I don't see this descriptor property you are talking about.. Could you enlightenme on this? If you mean the gump.xml - i only added fragments of it into gump/project/jakarta-commons-sandbox.xml in the gump cvs. As far as i understood, there is no need to keep them in the project itself. -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
Stefan Bodewig wrote: Hi all, two notes colored by my complete lack of Maven knowledge: (1) The descriptor of commons-compress sets a property named component.version and hopes to get this into the jar name, which obviously doesn't work that way. Maven still uses /project/currentVersion from the POM. I've adapted the descriptor to match the name we actually see just to get a successful build in Gump, but I'd prefer a way that allows us to get dated jar names via Maven. Probably we are just using the wrong property name or something like that. (2) The work entry inside the descriptor pointed to nowhere and there is no work entry for the generated test classes, still the test goal manages to load the freshly compiled test classes. This means that we are not getting the effect of build.sysclasspath=only in Maven builds. The jar overrides will catch the artifacts Gump knows about but Maven will happily let the goals (plugins, tasks, I don't know the correct terms) add more stuff to the classpath itself. For things like work directories for compiled classes this probably is good, but it may also lead to situations where Gump doesn't manage to substitute a jar from CVS with a freshly compiled one. Have been thinking about this issue for about a week and a bit. My conclusion is that the maven scenario is very similar to the magic scenario. To do real integration you need to be able do to something like set some special property so that magic or maven can take control over classloader definition in the knowledge that the build is a gump build (i.e. effects the repository cache that is used and the semantics concerning artifact handling). That means providing the current cache of artifact that have been generated so that magic or maven can map dependency reference to artifact in gumps cache. Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
On Tuesday 22 June 2004 00:32, Eric Pugh wrote: I don't know what extent you want to push back on the projects that gump builds, but it seems to me that they are either doing something that pushes maven beyond it's limits, or the decriptor might be out of date. I checked out jakarta-commons-sandbox/compress to investigate furthur, but I don't see this descriptor property you are talking about.. Could you enlightenme on this? I am guessing wildly, so don't pay to much attention to me :o) The question is, does Maven fully support disabling the normal 'repository management' allowing Gump to provide the artifacts for each project? Can Maven be told to ignore versions in the POMs ? I have so many questions about the Gump/Maven interaction, and it seems that the main Gump folks have little clue about Maven and vice versa. Maybe this has improved over the last few weeks, and I have just missed it. Well, I don't know... Could you (Eric or someone from the Maven camp) explain what 'hooks' has been provided for Gump? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
The question is, does Maven fully support disabling the normal 'repository management' allowing Gump to provide the artifacts for each project? Theoretically yes, but I think Stefan has disproved that it isn't leak-proof. Can Maven be told to ignore versions in the POMs ? Yes. I have so many questions about the Gump/Maven interaction, and it seems that the main Gump folks have little clue about Maven and vice versa. Maybe this has improved over the last few weeks, and I have just missed it. I don't know how Maven works internally, but this is what I can tell you about the Gump/Maven interaction works at the calling interface: http://gump.apache.org/metadata/maven.html What I didn't add there (but ought) is that Gump generates the build.properties file (setting properties these artifact overrides) before launching Maven. This file (and the others) are listed by Gump: http://brutus.apache.org:8080/gump/jakarta-commons-sandbox/commons-compress/index.html#Project-level+Files regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: gump/project jakarta-jmeter.xml
sebb2004/06/21 14:35:00 Modified:project jakarta-jmeter.xml Log: Make xpp and xstream separate sub-projects Revision ChangesPath 1.102 +32 -16gump/project/jakarta-jmeter.xml Index: jakarta-jmeter.xml === RCS file: /home/cvs/gump/project/jakarta-jmeter.xml,v retrieving revision 1.101 retrieving revision 1.102 diff -u -r1.101 -r1.102 --- jakarta-jmeter.xml20 Jun 2004 01:48:04 - 1.101 +++ jakarta-jmeter.xml21 Jun 2004 21:35:00 - 1.102 @@ -97,11 +97,10 @@ work nested=build/htmlparser/ work nested=build/jorphan/ -!-- Not available as Gump projects -- -work nested=lib/xpp3-1.1.3.4.D.jar/ -work nested=lib/xstream-1.0.1.jar/ - -!-- Allow http to build: -- +depend project=xpp3/ +depend project=xstream/ + +!-- Allow http to build: -- work nested=build/components/ !-- Allow Monitor to build -- @@ -113,8 +112,25 @@ regexp pattern=/BUILD FAILED/ subject=JMeter Build Failure/ /nag /project - - project name=jakarta-jmeter-cvs + + project name=xpp3 + url href=http://www.extreme.indiana.edu/xgws/xsoap/xpp// + description + Xml Pull Parser (in short XPP) is a streaming pull XML parser + and should be used when there is a need to process quickly and efficiently + all input elements. + /description + jar name=lib/xpp3-1.1.3.4.D.jar id=xpp3/ + /project + + project name=xstream + url href=http://xstream.codehaus.org// + descriptionXStream is a simple library to serialize objects to XML and back again + /description +jar name=lib/xstream-1.0.1.jar id=xstream/ + /project + + project name=jakarta-jmeter-cvs !-- Build JMeter from CVS versions of dependencies -- packageorg.apache.jmeter/package - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
My conclusion is that the maven scenario is very similar to the magic scenario. To do real integration you need to be able do to something like set some special property so that magic or maven can take control over classloader definition in the knowledge that the build is a gump build (i.e. effects the repository cache that is used and the semantics concerning artifact handling). That means providing the current cache of artifact that have been generated so that magic or maven can map dependency reference to artifact in gumps cache. It could go either way (Gump exposes it's repository of fresh artifacts to a builder, or builder exposes a mechanism [e.g. CLASSPATH] which Gump provides.) I like the idea of Gump maintaining a repository (as it does) that it provides to builders that are aware of such things. That said, if builder present standard mechanisms (like Ant does, like Maven might -- see ongoing discussion) I don't see why Gump doesn't support them. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: Unable to send...
A DOM4J fix would benefit 86 other projects, so thanks in advance... http://brutus.apache.org:8080/gump/project_todos.html http://brutus.apache.org:8080/gump/dom4j/dom4j/index.html#Project-level+Files Hmm, this show 'class not found'. I wonder if this is as simple as the test classes not being told to Gump in a work entry -- or some other classpath issues. http://brutus.apache.org:8080/gump/dom4j/dom4j/gump_file/TEST-org.dom4j.TestAddAttribute.xml.html error message=org.dom4j.TestAddAttribute type=java.lang.ClassNotFoundExceptionjava.lang.ClassNotFoundException: org.dom4j.TestAddAttribute at java.net.URLClassLoader$1.run(URLClassLoader.java:199) at java.security.AccessController.doPrivileged(Native Method) BTW: This is the classpath: http://brutus.apache.org:8080/gump/dom4j/dom4j/details.html#Classpath regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
