Re: temporarily disable nags for Directory in gump?
On Monday 15 August 2005 14:13, Brett Porter wrote: Would you like access? If you trust me to poke around without damaging anything when a project goes down, I'm happy to go in and fix it again - sure. They trusted me, so you'll be Ok :o) Heck, would you like to be on the Gump PMC? I have to admit my interests lay with getting projects to play together more than the implementation of gump itself, so I'm not sure I could do that justice :) Brett seems to fit my profile and since I stopped due to lost the morale when the huge success percentage drop occurred, I am sure he will be a great addition to the team. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running Apache Gump [vmgump-public]
Gang, In these notifications, the ASF spam check (whatever that is) injects a header; X-ASF-Spam-Status: No, hits=-9.6 required=10.0 tests=ALL_TRUSTED,INVALID_DATE,NO_REAL_NAME And I personally, check if INVALID_DATE is there and send it to spambox. Gumps date format; Date: 19 Jul 2005 05:26:38 Known working date format; Date: Mon, 18 Jul 2005 17:16:25 +0200 I suspect it is a missing timezone that triggers it, but I don't know RFC822 (I think) by heart, and the format could be fairly strict. Anyone interested in fixing such a minute issue ?? And I ain't going to learn Python, just for that :o) Cheers Niclas On Tuesday 19 July 2005 13:26, [EMAIL PROTECTED] wrote: There is a problem with run 'vmgump-public' (17072005_180001), location : http://vmgump.apache.org/gump/public The log ought be at: http://vmgump.apache.org/gump/public/gump_log.txt The last (up to) 50 lines of the log are : -- Perform Artifact Repository Search for : cocoon-block-slide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oucchhh!!!
On Wednesday 13 July 2005 01:35, Adam R. B. Jack wrote: I let a SPAM thorugh the moderation... So, sorry! Any we need to do about it ?? Funny, I haven't seen it on list. Maybe Stefan or I moderated it out first. Just got a Failure Notice from ezmlm, saying that after removing unacceptable HTML, nothing was left. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Broke log4j, any chance for a reset
On Sunday 27 February 2005 12:55, Curt Arnold wrote: Sorry, I inadvertently broke logging-log4j by removing its dependency on jakarta-oro. I did not intend to commit that, however I was surprised it failed since there is now a separate jar log4j-oro.jar that I would have expected would contain all the oro dependent code. I've modified the Gump descriptor so that problem should now be fixed. Is there any mechanism to restart Gump after this run is complete or better yet before the 200+ mail messages go out. Gump runs according a schedule, and a full build takes as long as the periodicity of the schedule. Restart is not really feasible. Stopping is probably better word. Right now the Kaffe build is running, and it has a lot of other issues I think, so no need to do anything. Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Kaffe] current issues
On Saturday 29 January 2005 01:26, Dalibor Topic wrote: I'm hacking on fixing Classpath's RMIC. I've got it mostly working in my local tree, but had to do some hacking on the Kaffe build system last week in between :( I am not sure if this has any importance at all, but I thought I should mention it. A problem for an RMI user came up on the mailing list, and was later solved to that it was not the Sun JDK's rmic being called. In that thread, the Sun engineered mentioned that the exception thrown could not happen, since rmic does not load the classes and instead uses an internal class inspection mechanism, also present in javac. Beginning of thread is available here; http://archives.java.sun.com/cgi-bin/wa?A2=ind0501L=rmi-usersF=S=P=844 Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Avalon failure
Hi, I just want to let everyone know that DPML switched its DNS service to our own management, and now pointing to our own servers, instead of the ibiblio.org one, and in the process, we didn't feel we needed to maintain the artifact repository that the Merlin testcases are using. In fact, we knew that someone (now apparent) was still using the old location, and wanted to redirect them over to the new one. But in this case, the source files to do that are in a locked Subversion repository. The change comprises http://www.dpml.net in a couple of places to be changed to http://repository.dpml.net If someone can provide me with a template on the directory by directory redirect/rewrite/external fetch or whatever it is called, so that; GET http://www.dpml.net/avalon does a GET http://repository.dpml.net/avalon but ONLY for '/avalon' and subdirs. and some rudimentary instructions, I can put that into the new server. Otherwise, Gump folks have to figure out how to deal with the situation; 1. Disable the testcases for the affected projects. 2. Get the access into the source and change it. 3. Close the building of these projects, and package them if necessary. 4. Other? Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to add a new packaged JAR?
On Tuesday 28 December 2004 07:43, Brett Porter wrote: Also, kerberos failed, unable to update out of SVN. I'm not sure if this is a once off or not: svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within Wrong directory checkout. directory/kerberos/trunk/kerberos should be directory/kerberos/trunk and then more projects should be added; main, core, protocol, and client I guess. I am too tired to do this right now. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to add a new packaged JAR?
On Tuesday 28 December 2004 07:43, Brett Porter wrote: Home: http://maven-plugins.sourceforge.net/maven-javaapp-plugin/index.html JAR: http://www.ibiblio.org/maven/maven-plugins/plugins/maven-javaapp-plugin-1.3 .jar I figured as this is not an Apache project, adding it as a package was desired, however I'm happy to build it from source if necessary. I have installed the package on brutus, but we should probably consider to build it from source. Many other SF.net projects are built from source. Also, kerberos failed, unable to update out of SVN. I'm not sure if this is a once off or not: svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within Is it possible someone could do a clean checkout of the kerberos module to ensure this doesn't happen next go round? Done. Removed the kerberos checkout as well as the workspace (maybe shouldn't have done that part :o) ). Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
EarthQuake near Sumatra
Hi, Before more people contact me about earth quakes, tsunamis and bad weather... First my mum calls, then Leo Sutic send mail, about stuff happening down here, so I looked it up on CNN. Strongest earth quake in the world for 40 years (fifth largest ever recorded) next to Sumatra, causing big tsunamis hitting the region. Est 4700 dead. Kuala Lumpur is 50-60km from the shore, so tsunamis are not a worry, and I live on 28th floor :o). Looking back, I actually felt the earth quake, although I didn't think it was one. I was very tired, doing some programming, and thought that the room was moving. I attributed it to me being in desparate need for sleep, and that the motion came from within. However, I also noticed that the water in a bottle in front of me moved slowly back and forth, but not more than I consider it part of my imagination. Without pondering too much over it, I just ignored the event and went on with my work. So, there are plenty of other people on this list living in within the reach of nature's wrath, mostly hurricane/cyclone territory. I am not one of those :o) Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sockets in testcases on Brutus.
Hi, Are there any restrictions (firewall) to open sockets on Brutus?? Some of the Directory testcases opens port (or next available) for listening and then executes tests against it as a client. Is there anything at OS level that prohibit this? Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project directory-eve.xml directory-janus.xml directory-kerberos.xml directory-ldap.xml directory-snickers.xml
On Thursday 23 December 2004 03:37, Brett Porter wrote: + property name=maven.jar.aspectjrt project=aspectj id=aspectjrt reference=jarpath/ ... depend project=aspectj/ Doesn't this mean that the depend should list the id too? I don't think it matters. The depend will only be used to put together the build dependency graph, i.e. the build order. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven properties having problems of some kind.
Brett, The POM contains; dependency groupIdgeronimo-spec/groupId artifactIdgeronimo-spec-jta/artifactId version1.0.1B-rc1/version /dependency dependency groupIdgeronimo-spec/groupId artifactIdgeronimo-spec-javamail/artifactId version1.3.1-rc1/version /dependency And the Gump descriptor has; depend property=maven.jar.geronimo-spec-jta project=jta id=jta / depend property=maven.jar.geronimo-spec-javamail project=javamail id=javamail / What reasons could there be that the build reports; The build cannot continue because of the following unsatisfied dependencies: geronimo-spec-jta-1.0.1B-rc1.jar geronimo-spec-javamail-1.3.1-rc1.jar This is for directory-naming-factory. Any clue? Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven properties having problems of some kind.
On Tuesday 21 December 2004 21:17, Stefan Bodewig wrote: On Tue, 21 Dec 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: And the Gump descriptor has; depend property=maven.jar.geronimo-spec-jta project=jta id=jta / depend property=maven.jar.geronimo-spec-javamail project=javamail id=javamail / Yes, but as children of project and not of maven. The property attribute doesn't have a meaning there. Hmmm... Ok. Hope you don't mind that I say it is somewhat confusing... I'll change the descriptor. Thanks Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project directory-eve.xml directory-janus.xml directory-kerberos.xml directory-ldap.xml directory-naming.xml directory-snickers.xml
I have noticed my mistake Correcting!! Niclas On Tuesday 21 December 2004 21:47, [EMAIL PROTECTED] wrote: niclas 2004/12/21 05:47:58 Modified:project directory-eve.xml directory-janus.xml directory-kerberos.xml directory-ldap.xml directory-naming.xml directory-snickers.xml Log: APplied the new-won knowledge of when the property attribute in depend elements are relevant Revision ChangesPath 1.4 +9 -9 gump/project/directory-eve.xml Index: directory-eve.xml === RCS file: /home/cvs/gump/project/directory-eve.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- directory-eve.xml 20 Dec 2004 09:04:38 - 1.3 +++ directory-eve.xml 21 Dec 2004 13:47:57 - 1.4 @@ -52,10 +52,10 @@ project name=eve-protocol maven goal=jar basedir=protocol property name=maven.final.name value=eve-protocol-@@DATE@@/ + depend project=jakarta-oro property=maven.jar.oro / + depend project=jakarta-regexp property=maven.jar.regexp / /maven -depend project=jakarta-oro property=maven.jar.oro / -depend project=jakarta-regexp property=maven.jar.regexp / depend project=antlr / depend project=snickers-codec / depend project=ldap-common / @@ -77,6 +77,7 @@ project name=maven-eve-plugin maven goal=jar basedir=plugin property name=maven.final.name value=maven-eve-plugin-@@DATE@@/ + depend property=maven.jar.velocity-dep project=jakarta-velocity id=velocity / /maven depend project=junit / @@ -84,7 +85,6 @@ depend project=antlr / depend project=ldap-common / depend project=eve-shared / -depend property=maven.jar.velocity-dep project=jakarta-velocity id=velocity / home nested=plugin / @@ -101,16 +101,16 @@ project name=eve-core maven goal=jar basedir=core property name=maven.final.name value=eve-core-@@DATE@@/ + depend project=jakarta-regexp property=maven.jar.regexp / + depend project=jakarta-oro property=maven.jar.oro / + depend property=aspectjrt.jar project=aspectj id=aspectjrt/ /maven -depend project=jakarta-regexp property=maven.jar.regexp / -depend project=jakarta-oro property=maven.jar.oro / depend project=commons-logging / depend project=commons-io / depend project=antlr / depend project=jdbm / depend project=ldap-common / -depend property=aspectjrt.jar project=aspectj id=aspectjrt/ depend project=eve-shared / depend project=eve-protocol / depend project=snickers-codec / @@ -135,10 +135,11 @@ project name=eve maven goal=jar basedir=main property name=maven.final.name value=eve-@@DATE@@/ + depend project=jakarta-regexp property=maven.jar.regexp / + depend project=jakarta-oro property=maven.jar.oro / + depend property=aspectjrt.jar project=aspectj id=aspectjrt/ /maven -depend project=jakarta-regexp property=maven.jar.regexp / -depend project=jakarta-oro property=maven.jar.oro / depend project=commons-lang / depend project=commons-logging / depend project=commons-collections / @@ -146,7 +147,6 @@ depend project=antlr / depend project=jdbm / depend project=ldap-common / -depend property=aspectjrt.jar project=aspectj id=aspectjrt/ depend project=eve-shared / depend project=eve-protocol / depend project=snickers-codec / 1.5 +1 -1 gump/project/directory-janus.xml Index: directory-janus.xml === RCS file: /home/cvs/gump/project/directory-janus.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- directory-janus.xml 21 Dec 2004 12:37:25 - 1.4 +++ directory-janus.xml 21 Dec 2004 13:47:57 - 1.5 @@ -138,12 +138,12 @@ project name=janus-script maven goal=jar basedir=script property name=maven.final.name value=janus-script-@@DATE@@/ + depend property=maven.jar.xercesImpl project=xml-xerces / /maven depend project=janus-api / depend project=janus-impl / depend project=dom4j / -depend property=maven.jar.xercesImpl project=xml-xerces / depend project=xml-apis / depend project=jmock / 1.5 +3 -3 gump/project/directory-kerberos.xml Index: directory-kerberos.xml === RCS file: /home/cvs/gump/project/directory-kerberos.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- directory-kerberos.xml 21 Dec
Re: cvs commit: gump/project directory-eve.xml directory-janus.xml directory-kerberos.xml directory-ldap.xml directory-snickers.xml
On Tuesday 21 December 2004 22:17, Stefan Bodewig wrote: On 21 Dec 2004, [EMAIL PROTECTED] wrote: Ooops... learning is slow today. It was OK before your change. ./validate complained. Now you also need to add reference=jarpath to all new property elements. ok. will do... later :o) (by lazy consensus, very lazy...) Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Backup moderator needed
On Monday 20 December 2004 17:15, Stefan Bodewig wrote: I won't be online as much as usual (read, even less than usual) over the next three weeks because of the holidays. While the general list and the pmc list have two moderators (Adam and myself), I'm the sole moderator of the commits list. Therefore we need a second moderator for that list. If anybody wants to be added as moderators for the other lists as well, that's fine with me. Any volunteers? You can add me, provided I am taken out upon my later request ;o) Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
On Monday 13 December 2004 13:16, Adam R. B. Jack wrote: but I really figured the Gump metadata would be tweaked to fit what Maven had defined. Shame if that isn't so. Well, there are two sides to this story; 1. Gump should circumvent any obstacle provided by the buildsystem in each project. 2. Maven wants to automatically generate a functional Gump descriptor. If you do 2. in Maven, you will need some help from the projects to make it so. If you don't care about 2., you can probably manage with the existing features in Maven, and need to look at the inter-project issues, such as * Mismatch between Gump project names and Maven artifactIDs. * Multiple artifactIDs with the same name, but different groups. * Same artifacts with different artifactIDs and different groups. If you do 2., you can rely on that being set up in each Maven project to aid Gump (just like has been done with Magic for the Avalon projects). I can sense that Brett and myself are leaning more towards the 2. , whereas for instance Adam and Stefan(o) are more favourable of 1. Both have their technical and social strengths. But I think we need to conclude which way to go. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Gump 3.0 - Database Model
On Monday 13 December 2004 09:09, Stefano Mazzocchi wrote: Eric, I really don't care what ID we choose, as long as it does identify something univocally also in a global and distributed environment. RDF ? Isn't RDF a perfect fit for this kind of problems ? Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
On Monday 13 December 2004 16:24, Stefan Bodewig wrote: I think at least Stefan(o) prefer Gump an approach where Gump can parse Maven POMs directly. :o) Cool. But you are back to some of the problems listed for approach 1., e.g. there are artifacts that are not inter-project consistent. So, POM *alone* is not enough, but can remove the need for a gump goal in Maven. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project directory.xml
On Tuesday 14 December 2004 07:00, [EMAIL PROTECTED] wrote: ips 2004/12/13 15:00:16 Added: project directory.xml Log: first cut at a module descriptor for the Directory project - currently contains only a project def for the Naming subproject This is already work in progress. See the profile/gump.xml for the module inclusions. The Directory descriptors are kept there for the time being. Thanks for your interest, but I think you have wasted your time. Btw, wondering who [EMAIL PROTECTED] was, I went to http://www.apache.org/~jim/committers.html and no listing. Ian Springer, I think you should enquire why that is the case. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: native line-endings
On Tuesday 14 December 2004 19:47, Stefan Bodewig wrote: This has to be done by each developer individually, correct? Correct. Find my config file below. Cheers Niclas ### This file configures various client-side behaviors. ### ### The commented-out examples below are intended to demonstrate ### how to use this file. ### Section for authentication and authorization customizations. ### Set store-password to 'no' to avoid storing your subversion ### passwords in the auth/ area of your config directory. ### It defaults to 'yes'. Note that this option only prevents ### saving of *new* credentials; it doesn't invalidate existing ### caches. (To do that, remove the cache files by hand.) # [auth] # store-password = no ### Section for configuring external helper applications. ### Set editor to the command used to invoke your text editor. ### This will override the environment variables that Subversion ### examines by default to find this information ($EDITOR, ### et al). ### Set diff-cmd to the absolute path of your 'diff' program. ### This will override the compile-time default, which is to use ### Subversion's internal diff implementation. ### Set diff3-cmd to the absolute path of your 'diff3' program. ### This will override the compile-time default, which is to use ### Subversion's internal diff3 implementation. ### Set diff3-has-program-arg to 'true' or 'yes' if your 'diff3' ### program accepts the '--diff-program' option. # [helpers] # editor-cmd = editor (vi, emacs, notepad, etc.) # diff-cmd = diff_program (diff, gdiff, etc.) # diff3-cmd = diff3_program (diff3, gdiff3, etc.) # diff3-has-program-arg = [true | false] ### Section for configuring tunnel agents. # [tunnels] ### Configure svn protocol tunnel schemes here. By default, only ### the 'ssh' scheme is defined. You can define other schemes to ### be used with 'svn+scheme://hostname/path' URLs. A scheme ### definition is simply a command, optionally prefixed by an ### environment variable name which can override the command if it ### is defined. The command (or environment variable) may contain ### arguments, using standard shell quoting for arguments with ### spaces. The command will be invoked as: ### command hostname svnserve -t ### (If the URL includes a username, then the hostname will be ### passed to the tunnel agent as user@hostname.) If the ### built-in ssh scheme were not predefined, it could be defined ### as: # ssh = $SVN_SSH ssh ### If you wanted to define a new 'rsh' scheme, to be used with ### 'svn+rsh:' URLs, you could do so as follows: # rsh = rsh ### Or, if you wanted to specify a full path and arguments: # rsh = /path/to/rsh -l myusername ### On Windows, if you are specifying a full path to a command, ### use a forward slash (/) or a paired backslash (\\) as the ### path separator. A single backslash will be treated as an ### escape for the following character. ### Section for configuring miscelleneous Subversion options. [miscellany] ### Set global-ignores to a set of whitespace-delimited globs ### which Subversion will ignore in its 'status' output. global-ignores = *.iml *.ipr *.iws *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store target ### Set log-encoding to the default encoding for log messages # log-encoding = latin1 ### Set use-commit-times to make checkout/update/switch/revert ### put last-committed timestamps on every file touched. use-commit-times = yes ### Set enable-auto-props to 'yes' to enable automatic properties ### for 'svn add' and 'svn import', it defaults to 'no'. ### Automatic properties are defined in the section 'auto-props'. enable-auto-props = yes ### Section for configuring automatic properties. ### The format of the entries is: ### file-name-pattern = propname[=value][;propname[=value]...] ### The file-name-pattern can contain wildcards (such as '*' and ### '?'). All entries which match will be applied to the file. ### Note that auto-props functionality must be enabled, which ### is typically done by setting the 'enable-auto-props' option. [auto-props] *.bat = svn:eol-style=CRLF;svn:executable *.block = svn:eol-style=native *.c = svn:eol-style=native *.cgi = svn:eol-style=native *.cpp = svn:eol-style=native *.css = svn:eol-style=native *.dll = svn:mime-type=application/octet-stream *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.ent = svn:eol-style=native *.gif = svn:mime-type=image/gif *.h = svn:eol-style=native .htaccess = svn:eol-style=native *.html = svn:eol-style=native *.jar = svn:mime-type=application/octet-stream *.jpg = svn:mime-type=image/jpeg *.java = svn:eol-style=native *.meta = svn:eol-style=native *.png = svn:mime-type=image/png *.properties = svn:eol-style=native *.sequence = svn:eol-style=native *.sh = svn:eol-style=LF;svn:executable *.svg = svn:eol-style=native *.txt = svn:eol-style=native *.x* = svn:eol-style=native Makefile = svn:eol-style=native KEYS = svn:eol-style=native -- +--//---+ /
Re: cvs commit: gump/project directory.xml
On Tuesday 14 December 2004 10:06, Ian Springer wrote: Fyi, the reason I need a Gump descriptor for naming is because I'd like to make it a dependency of the apollo project, on which I'm a committer. We currently depend on the Tomcat naming jars, but would like to switch over. The directory-naming shouldn't be too hard to get operational. However, it consist of two projects, not one. See https://svn.apache.org/repos/asf/incubator/directory/naming/trunk/gump.xml I think I'll have these Ok as soon as Log4J is back to be operational (they have been notified). Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Nagging
FYI, it seems that Pre-Requisite Failed is getting nagged, whilst Build Failure doesn't. Example; Directory project got a couple of nags on; codec ldap-common eve-shared maven-eve-plugin all because dependencies have failed to build, but no nags on projects that actually failed, such as; directory-naming-core directory-naming-factory eve eve-dib eve-shared eve-protocol eve-kerberos and others. So there is something very wrong. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More cycles for kaffe
On Sunday 12 December 2004 02:44, Davanum Srinivas wrote: Folks, Any objections to add more cycles for a few weeks till things settle down? (all times PST) 0 - public --official 3 - kaffe 6 - jdk15 9 - kaffe 12- test 15- kaffe 18- public 21- kaffe There is an additional problem, and perhaps the Kaffe build actually leviates it to some extent. The thing is; the public/ build now takes ~4 hours, so the three hour gap is too short for consequetive public/ builds. OTOH, I am not sure what happens if kaffe/ starts before public/ finish - I assume they both proceeds, which will be a race for CPU. Also, from my PoV (trying to get directory to build), could you perhaps also swap the public-1800 with the jdk15-0600 or the test-1200, as it would help me a lot. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nagging
On Sunday 12 December 2004 04:40, Adam R. B. Jack wrote: all because dependencies have failed to build, but no nags on projects that actually failed, such as; Yes, indeed. Could you forward a few (or all) of them to me, P2P please? done. don't think you want them all. :o) cheers niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory projects
On Friday 10 December 2004 19:48, Brett Porter wrote: Ok, so has directory been disabled because of this? I'm about to regenerate the descriptors, and after that will comment out all those above until we can sort out what to do with them... Hold the horses a bit, Brett. There are errors being reported for the Eve descriptor, by the ./validate script. fetching http://svn.apache.org/repos/asf/incubator/directory/eve/trunk/gump.xml... ./tmp/project/gump.xml:14: validity error: Element url was declared EMPTY this one has content /url ^ ./tmp/project/gump.xml:16: validity error: No declaration for attribute module of element svn svn repository=apache-incubator-svn module=directory/eve/trunk/ ^ ./tmp/project/gump.xml:16: validity error: Element svn was declared EMPTY this one has content /svn ^ ./tmp/project/gump.xml:20: validity error: Element property was declared EMPTY this one has content /property ^ ./tmp/project/gump.xml:27: validity error: Element home was declared EMPTY this one has content /home ^ ./tmp/project/gump.xml:29: validity error: Element jar was declared EMPTY this one has content /jar ^ ./tmp/project/gump.xml:40: validity error: Element property was declared EMPTY this one has content /property ^ ./tmp/project/gump.xml:57: validity error: Element home was declared EMPTY this one has content /home ^ ./tmp/project/gump.xml:59: validity error: Element jar was declared EMPTY this one has content /jar ^ ./tmp/project/gump.xml:70: validity error: Element property was declared EMPTY this one has content /property ^ ./tmp/project/gump.xml:85: validity error: Element home was declared EMPTY this one has content /home ^ ./tmp/project/gump.xml:87: validity error: Element jar was declared EMPTY this one has content /jar ^ ./tmp/project/gump.xml:98: validity error: Element property was declared EMPTY this one has content /property ^ ./tmp/project/gump.xml:133: validity error: Element home was declared EMPTY this one has content /home ^ ./tmp/project/gump.xml:135: validity error: Element jar was declared EMPTY this one has content /jar ^ ./tmp/project/gump.xml:146: validity error: Element property was declared EMPTY this one has content /property ^ ./tmp/project/gump.xml:187: validity error: Element home was declared EMPTY this one has content /home ^ ./tmp/project/gump.xml:189: validity error: Element jar was declared EMPTY this one has content /jar The EMPTY is annoying, but strictly speaking, they should be, whilest they actually contain linefeed + spaces. Need to be fixed, and shouldn't be too hard. Also, the svn tag doesn't have module attribute, it should be a dir attribute. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory projects
On Friday 10 December 2004 20:19, Brett Porter wrote: Ok, I still have to do the EMPTYs, but can you take another look? (or is there a way I can do this?) If you commit the Eve Gump descriptor, then go to CVS Gump profile/ dir and open the gump.xml file, you will find the 7 directory module entries commented out. If you uncomment that (but don't commit it), then go to the CVS top-dir, you find a ./validate script (provided you run Linux/Unix/Cygwin), which you can invoke and get information about what Gump doesn't like. (Note, there are some other validation failures at the moment) Cheers Niclas Are you sure the svn tag is right? The doco says it just takes an URL (though this is fine if it works!) - Brett On Fri, 10 Dec 2004 23:07:52 +1100, Brett Porter [EMAIL PROTECTED] wrote: The EMPTY is annoying, but strictly speaking, they should be, whilest they actually contain linefeed + spaces. Need to be fixed, and shouldn't be too hard. Ok, I'll have to look at this more. The templating I'm using always does this - I'll need to track down the option not to. In the mean time, I'll do it by hand. Also, the svn tag doesn't have module attribute, it should be a dir attribute. Fixed. - Brett Cheers Niclas -- +--//---+ / http://www.dpml.net / / 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] -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory projects
On Saturday 11 December 2004 01:08, Stefan Bodewig wrote: Yes, see my response to the Failed to run Gump mail minutes before I removed the descriptors from the profile. One of the descriptors had a home nested=/ Element, which caused Gump to fail. 1. A lot of mispointed projects -- no big deal, can be dealt with one by one, right? 2. home nested=/ plus a proper home nested=janus / in the same project if that possibly makes it worse. Yes, it is Gump's fault, but then again it doesn't make any sense as a descriptor-element either. Was a duplicate old one hanging around that I didn't notice. I'll try to enable this for the next run (if any), and see what happens. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory projects
On Saturday 11 December 2004 01:11, Niclas Hedhman wrote: On Friday 10 December 2004 20:19, Brett Porter wrote: Ok, I still have to do the EMPTYs, but can you take another look? (or is there a way I can do this?) If you commit the Eve Gump descriptor, then go to CVS Gump profile/ dir and open the gump.xml file, you will find the 7 directory module entries commented out. If you uncomment that (but don't commit it), then go to the CVS top-dir, you find a ./validate script (provided you run Linux/Unix/Cygwin), which you can invoke and get information about what Gump doesn't like. (Note, there are some other validation failures at the moment) And validate atm says that these are now OK. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory projects
On Saturday 11 December 2004 01:08, Stefan Bodewig wrote: Yes, it is Gump's fault, but then again it doesn't make any sense as a descriptor-element either. Btw, I do it myself all the time; When a testcase fail, it is easier to remove the test ;o) Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: directory projects
On Wednesday 08 December 2004 22:28, Stefan Bodewig wrote: The descriptors reference a lot of not (or no longer) existing project names. I'm not sure whether this causes the breakage of the JDK 1.5 build (rather not), but they should probably get fixed first. I'll remove them for now. Nah!!! I am trying to bring the Directory project into Gump, and made a very rough first cut at it... If you find them annoying, just ignore :o) Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On Tuesday 30 November 2004 20:18, Geir Magnusson Jr wrote: On Nov 30, 2004, at 6:19 AM, Eric Pugh wrote: Geir's email highlights a very clear issue with the whole deprecation/version cycle. He can't switch to log4j until it releases. They don't want to keep deprecated code around for forever. I'm not asking for forever. Just one version... even a short lived one... My take away lesson is really more of a reaffirmation - don't depend on outside things if you can help it... Log4J has otherwise been very generous with having deprecated code around, but when I asked explicitly if this was a chagne for 1.3 and whether that means that everyone who uses RFA have to change the config files, I got from Ceki the answer; Yes to those two questions. Very strange change of attitude, and I don't know why this is happening. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: failure notice
On Tuesday 30 November 2004 21:32, Ceki Glc wrote: At 03:39 AM 11/30/2004, Geir Magnusson Jr wrote: anyway, the interesting thing is the problem I have fixing Velocity so Gump is happy ... Niclas Hedhman informed us of this problem. There was a conscious choice to remove the old RollingAppender and replace with something better. Gump is just a fuzzy user ;o) So irregardless of that, how come this mainly incompatible change is being made in a .x release? Wouldn't it be so much better to keep the old RFA still in there with a massive deprecated sign (possibly in the outputs as well), for one cycle? Even better if the older one delegates to the newer one, but that is less important... As the HEAD now is, you are asking an enormous amount of people to make changes if they want to upgrade to a newer version, which on paper (if anyone ever believes the Dewey convention) says it is a compatible upgrade with more features. But, then again, I am perhaps too sensitive and lazy, to see the beauty of culling the class without warning. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Picking up the ball from Niclas (ugh!) on Velocity
On Tuesday 30 November 2004 07:45, Stefano Mazzocchi wrote: Gump is about establishing communication channels between development communities. On the other hand, if you are interested in creating a social engineering support tool and you are willing to get your hands dirty in python and prepare to have a huge ton of patience to convert a few hundreds people to a very difficult concept, The rule should be to start fixing gump and fix the communication channels rather than fixing the metadata to route around the problems. Cool, but then you told me Don't change people we should work around them [projects not willing to co-operate]... I would call that mixed signals... ;o) Cheers Niclas P.S. Let me know when you figured out that Java is a better tool after all :o) so I can help more actively. -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Standing back (for a while?)...
Gang, I have decided to step away from Gump for a while, and the main reason is that I find it depressing to work with... Increments of overall success is slow, and decrements of overall success is fast. And during the period of big showstoppers, entropy sets in in all non-building projects so that when the big showstopper is resolved, a lot of small cases are back. I find that there must be something fundamentally wrong with Gump, if it self-deteriorate so quickly. Personally I think the solution is that the Gump group needs to work more intimately with the Ant/Maven and other build system groups, to put in the continous integration support directly into those tools, instead of the manual labour of bolting it on externally. I might be back later, but for now I wish you all Good Luck. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project excalibur.xml
On Monday 22 November 2004 05:48, Brett Porter wrote: 1. Project had no jakarta-velocity dependency 2. Maven build started failing on velocity missing 3. jakarta-velocity was added to gump descriptor to correct, though excalibur doesn't need it. What probably happened was the local repository was flushed - it was originally set up to have a series of dependencies for plugins. So IIUIC, one of the plugins that is used to build Excalibur needs Velocity? And that you don't need to declare that in a POM normally, and this shows up, since Maven is running -offline, and the plugin in question can't operate and can't download... So, i.e. there shouldn't be a velocity dependency in the Excalibur Gump descriptor, but we should ensure that the Maven installation is proper. Who has access to brutus enough to help me start planning where to install Maven as it gets built so that other projects can use it? Adam was the main person I spoke to initially and has been very busy/quiet lately. AFAIK, most people around here; Stefano, Adam, Stefan, me, Leo and probably others. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project excalibur.xml
On Sunday 21 November 2004 21:29, Leo Simons wrote: +depend project=jakarta-velocity/ I don't get it. What's going on? Why are things failing? AFAIK excalibur doesn't use velocity... I know, and asked the same question some time ago. I can only conclude that Maven needs it somehow and doesn't have it. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project excalibur.xml
On Monday 22 November 2004 03:43, Brett Porter wrote: Is this a Maven generated descriptor adding them in, or hand-rolled and added because Maven needs it? Not sure what you mean. Projects in Excalibur suddenly started reporting that some velocity-xxx.jar could not be found. The project.xml didn't have it declared, and AFAIK (Leo would know better) no code changes were made to the Excalibur codebase either. Hence the surprise. Getting this sorted out is getting really close to the top of my list (it was going to be after the 1.0.1 release, but some small issues have cropped up that are forcing a 1.0.2 release), so I'll get to it after that. This brings up the issue; Gump seems to be using 1.0. Is that sufficient or is an upgrade recommended? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jakarta-turbine-2.xml
On Thursday 18 November 2004 19:19, Stefan Bodewig wrote: On 18 Nov 2004, [EMAIL PROTECTED] wrote: removed unknown deps. will only lead to Maven complaining about missing jars. Maybe we should fake those with dummy projects? Has there ever been a avalon-activation-spi project? Yes, at some point. I have no idea how they manage to depend on it though, since it was a fairly internal module in Merlin. Steve?? Any clue? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project excalibur.xml
On Thursday 18 November 2004 20:15, Stefan Bodewig wrote: On Thu, 18 Nov 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: On Thursday 18 November 2004 18:08, [EMAIL PROTECTED] wrote: +depend project=jakarta-velocity/ +depend project=jakarta-velocity/ +depend project=jakarta-velocity/ This report by Maven is highly strange, since I can't find that Excalibur has a velocity dependency. In my experience this tends to happen quite often. commons-xo has been building with a far smaller set of dependencies using Ant than the Maven project file required. Same is true for a few other Maven projects I looked into. Ok. But in this case this dependencies has appeared out of nowhere, since those excalibur projects used to build in Gump with Maven, and AFAIK no changes has been made to them... IMHO, quite weird. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump Failure
Gang, I think the following Gump failure could be related to recent Log4J changes... http://brutus.apache.org/gump/public/ws-axis/ws-axis/gump_work/build_ws-axis_ws-axis.html Any input is appreciated. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Hivemind build on Gump
Hi, We are trying real hard to push Gump the final mile[1] to 100% success rate, and we are now so close that even small issue are being addressed. If we look at; http://brutus.apache.org/gump/public/jakarta-hivemind/jakarta-hivemind-compile/gump_work/build_jakarta-hivemind_jakarta-hivemind-compile.html we can see; 1. Download of commons-logging occurs. The preferred method would be to check if some c-logging class exist, prior to the download. Gump provides for the classes in the classpath. (minor issue) 2. javassist-3.0-rc1 is trying to be downloaded from ibiblio.org/maven, and that doesn't exist either. Either do the above (1.) since Gump is providing the HEAD build of the said package, or tell us how to tell the build script where to find this jar. Thanks for your co-operation. Niclas Hedhman P.S. Please respond to the [EMAIL PROTECTED] [1] The current success rate is 90% and here is the current list of failing projects; http://brutus.apache.org/gump/public/project_todos.html -- +-//---+ | http://www.bali.ac | | http://niclas.hedhman.org | +--//--+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re; cvs commit: gump/project jakarta-turbine-fulcrum.xml
On Friday 05 November 2004 17:00, [EMAIL PROTECTED] wrote: -depend project=commons-beanutils-core/ +depend project=commons-beanutils/ Keep changing this poor dependency back and forth doesn't help... Next run you will get that commons-beanutils-core can not be found in the Maven build. I am too busy to fix this, but I think the property maven.commons-beanutils-core.jar needs to be set to the Jar in question. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re; cvs commit: gump/project jakarta-turbine-fulcrum.xml
On Friday 05 November 2004 19:06, Eric Pugh wrote: Sorry about that.. I am flailing a bit.. I think I get it.. The project is called commons-beanutils. So, that is the dependency in gump I need. But, the jar is called commons-beanutils-core.jar, so that is the dependency I need in Maven. And, the maven.commons-beanutils-core.jar will map between the two, correct? Correct. BUT I am not entirely sure that properties work with maven as one would expect. trial and error I guess. Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Seeing results of Maven unit tests?
On Wednesday 03 November 2004 17:13, Eric Pugh wrote: Unfortunantly they are all work arounds to the fact that I can't see the unit test results. But also, it is because in fulcrum cache we have two unit tests. One is a quick is it working and another is a longer running test the cache for 2 minutes test. Ok. If you want a property to be set, just set it; maven property name=gump.isRunning value=true / /maven should work. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Seeing results of Maven unit tests?
On Tuesday 02 November 2004 23:18, Eric Pugh wrote: Cool, it is GUMP-87. So, the files output by gump are not located someplace that I can browse via HTTP then huh.. Anyway I could get permissions to logon to the box and see? It is not for me to grant, so meanwhile here is the relevant (I hope) section of the TEST-org.apache.fulcrum.cache.CacheTest.txt [DEBUG] Starting container... [DEBUG] Loading the service container class org.apache.fulcrum.yaafi.framework.container.ServiceContainerImpl [DEBUG] Instantiating the service container class org.apache.fulcrum.yaafi.framework.container.ServiceContainerImpl [DEBUG] Setting applicationRootDir to /home/gump/workspaces2/public/workspace/jakarta-turbine-fulcrum/cache [DEBUG] Service Framework is starting up [DEBUG] Using the following applicationRootDir : /home/gump/workspaces2/public/workspace/jakarta-turbine-fulcrum/cache [DEBUG] Using the following tempRootDir : /tmp [DEBUG] Looking for src/test/TestComponentConfig.xml in the application directory [DEBUG] Successfully located src/test/TestComponentConfig.xml [DEBUG] Looking for src/test/TestRoleConfig.xml in the application directory [DEBUG] Successfully located src/test/TestRoleConfig.xml [DEBUG] Looking for /parameters.properties as absolute file location [DEBUG] Looking for /parameters.properties using the class loader [WARNING] Unable to locate /parameters.properties [DEBUG] Loading the implementation class for cache [DEBUG] Instantiating the implementation class for cache [DEBUG] Incarnating the service cache [DEBUG] LogEnabled.enableLogging() for cache [DEBUG] Configurable.configure() for cache [DEBUG] Initializable.initialize() for cache [DEBUG] Service Framework is up and running [INFO] YaffiContainer ready. [DEBUG] Disposing of container... [INFO] Disposing all services [DEBUG] All services are disposed [INFO] YaffiContainer has been disposed. - --- Testcase: testRefreshableTimeToLive(org.apache.fulcrum.cache.CacheTest): FAILED Received unexpected ObjectExpiredException exception when retrieving refreshable object after ( 6001 millis) junit.framework.AssertionFailedError: Received unexpected ObjectExpiredException exception when retrieving refreshable object after ( 6001 millis) at org.apache.fulcrum.cache.CacheTest.testRefreshableTimeToLive(CacheTest.java:476) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Seeing results of Maven unit tests?
On Wednesday 03 November 2004 01:08, Eric Pugh wrote: I've seen this error periodically, and to be honest, I don't like this test.. I don't really want to run it except on demand.. Is there any environment variable that tells me I am running in Gump that I can get? Anything like: if (System.getProperty(gump)==true) ignore test... Would setting the goal attribute in the maven element to something like jar work?? I think that you can also tell Maven not to report testcase failures as errors with a property. Then the question is if that property can be fed through the Maven element, and I think so. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
On Monday 01 November 2004 17:02, Conor MacNeill wrote: In effect, barcode4J acts as a testcase for its dependencies and you propose to remove that test. I understand the motivation, I'm not particularly concerned, but there is a potential downside, which I thought was worth noting. Very good observation, and the importance of external dependees will increase for Apache projects at a 'higher level', which don't have internal dependees. This can OTOH still be achieved by discriminately not build from the external project HEAD, and instead use release tagged snapshots. That provides IMHO the best of both for the ASF side of the equation. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
On Monday 01 November 2004 17:00, Leo Simons wrote: Kaffe is very much a leaf not a dependency (I know no ASF project that can only be built using Kaffe), yet using it for experimental runs doubles the amount of cpu and disk space used. For the record, there are 8 attempts at starting a Gump build every day. 1 is Kaffe, 1 is JDK1.5, 1 is 'test' and the others are the official build. So, it is not completely accurate to say that the Kaffe build instance doubles CPU/disk resources. While I appreciate the goal of being able to have a truly free java stack and how using Kaffe to build ASF projects helps towards attaining that goal, we're also doing public service towards the GNU people in this way. Looking at the fact that a Kaffe developer (dalibor) has taken interest in Gump, installed his own instance and trying hard to get things going, is IMHO a good testament to the appreciation of Gump. If you have a figure showing this saves significant cpu/disk space that we need for other stuff, you'll get (grudgingly) a +1. CPU/disk is basically a financial issue. If it is constrained today, we can take temporary measures to exclude projects to make room. Some external dependee projects don't build, and is 'annoying' in the reports. We can either remove them, or choose a better snapshot from their CVS. Those are short-term issues, and I think that removal of non-fixed dependee projects are adequate in the short-term. What we should start discussing is, how do we scale Gump 'real big'? If company A, can take part of a massive Gump build, provided that they make server(s) available for a massively parallelized builds, then I think *many* would like to be part of the Gump service, and therefor ASF will have access to 'unlimited' CPU/disk resources for those builds (i.e. each participants will make available more resource than their part will consume). IMHO, this is a tangible, highly interesting and highly valuable challenge, and not beyond reach. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
On Monday 01 November 2004 19:29, Eric Pugh wrote: Related to this, I am starting to think about dependencies not just in a is it a good dependency to have but in a what challenges will having this dependency give me in Gump land, which isn't a great thing... Hmmm... I wonder if such thought is a sign of Gump creating problem for you, or if Gump amplifies future trouble with external dependencies?? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
On Monday 01 November 2004 23:41, Stefano Mazzocchi wrote: So, let me rephrase my proposal: If a project: 1) is not an ASF project 2) no ASF project depend on it 3) has been broken for a while and shows no sign of activity (gump-wise) we remove it from the gump.xml profile that brutus runs. As a result: 1) we save some time and space 2) we obtain a more reasonable indication that the gump status *is* is a measure of the community integration +1 -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Kaffe instance and ant-bootstrap
On Monday 01 November 2004 21:12, Dalibor Topic wrote: Since you're using the normal debian packages, setting a few additional env vars should do the trick for the bootstrap with kaffe: extras for ant bootstrap with kaffe ## ## Use jikes with kaffe's class libraries on bootclasspath export JAVAC=jikes-kaffe ## Jikes doesn't like javac.source=1.2 in build.xml, but only accepts 1.3 or 1.4 export ANT_OPTS=-Dbuild.compiler=jikes -Djavac.source=1.3 So, are you suggesting that we do the above, or are you suggesting that we should prepare to get Kaffe from CVS? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running Apache Gump...
On Sunday 31 October 2004 21:30, Adam R. B. Jack wrote: Yikes, this is a new one on me. Ahh ... clocks changed back an hour in the middle of a run, perhaps. Grins a little embarrassed, shrugs, oh well... Simple solution for this, which I wonder why not every single host in the world use; UTC. Except for Americans it would make life a lot easier, since who have a clue about what PST and PDT is, and when it is either... ;o) Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] removing non-ASF leaves from the workspace
On Sunday 31 October 2004 01:55, Stefano Mazzocchi wrote: there are a few projects that gump builds that are not ASF projects and are not used by any ASF project. I think the ASF already has enough things to build for ourselves and gump is not a public service. I personally think that it is abusive for comitters to use their access to add projects that are not required. Examples of such projects are Barcode4j, Antworks, Smartfrog, but I'm sure I can found more (and, in fact, I'll write some code to outline those and automate the checks). I propose that we remove those projects from the gump.xml profile that is ran on brutus (we can keep the descriptors there, that doesn't hurt) but I would like to remove all those leaves projects from using cpu/disk space. WTDY? What Think Do I? :o) First a bit off-topic; isn't this also becoming a scalability issue problem for the ASF model of oversight as well? The more external dependencies that are introduced into the codebase, the higher the risk that non-ASF projects are introducing trojan horses and other security-related issues. There seems to be various levels of desire among ASF committers to make external dependencies, even choosing external ones over viable ASF ones, often with the argument of level of community activity. Anyway, that aside, I think that as long as Gump is not a P2P federation of externally provided CPU resources, I don't see a reason why ASF should build any leaf nodes that no ASF projects are dependent upon. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Copy junit reports doesn't work...
Python-masters, Look at the content in the directory ~/workspaces/public/results/cocoon/cocoon/gump_file on brutus. There are two things that are not right; 1. Everything has an additional .html to it. 2. Directories are not copied recursively. Apparently there is an attemp somewhere to copy the junit results to a browsable output area, which is great now when we will be hitting more and more testcase failures, and quickly provide the output to the people it concerns. Since it is almost in place, can someone have a quick look at it, and see if there is a quick fix. Cheers Niclas P.S. I have been aimlessly looking at heaps of Python code, and the only copying I can find is in python/gump/util/sync.py, and that looks Ok to me. And the only place where html seems to be added to the mix is in the python/gump/actor/document/xdocs/ package, which I would guess shouldn't be involved in this... -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project xml-apis.xml
On Wednesday 27 October 2004 23:46, Stefan Bodewig wrote: On 27 Oct 2004, [EMAIL PROTECTED] wrote: Adding the xmlParserAPIs for some Maven projects in Fulcrum. + project name=xmlParserAPIspackage=jetty-5.0.RC4/ Isn't this the same jar that we created during the Xerces build? The 2.5 in the jar name in Jetty suggests Xerces-J 2.5 to me. Perhaps. Feel free to try to get the name xmlParserAPIs to map against the Maven artifactID of the same name. ATM, type=boot jars will not map to Maven jar overrides, and I couldn't figure out any other way to handle this. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
On Tuesday 26 October 2004 17:39, Eric Pugh wrote: I guess that would help. However, a challenge for me is that everytime I add a dependency to my project.xml I also need to inform gump. As I have gotton more and more used to Maven, I don't even think about dependencies beyond manipulating project.xml. I agree with you on this point, and... However, you are right that the module reference being able to point to external source repositories addresses the access issue. ... this was the only thing I was commenting on. Sorry if that wasn't clear. I think we all want to minimize the synchronization between a project's dependency resolution system and Gump's resolution system. Magic has a solution, since Gump support was built-in from the beginning. OTOH, Magic is only used in Avalon, and that is being shut down, so even though it is a highly capable build system, its relevance here is diminishing rapidly. Maven is shakey, i.e. automatic generation doesn't work, mostly because it doesn't have explicit Gump treatment in the POM. If Maven is not going to change the POM DTD to accommodate for Gump (== unlikely, since it would also require the projects to use that feature), then to achieve completely automated generation of Gump descriptors from the Maven Gump goal, we need to ensure that projects are name-synced with Maven artifact IDs, or have an artifactId attribute for each of the projects. Ant projects are treated according to a template of classpath injection, BUT some projects do their own downloads, and I wonder if there are some that actually bypasses the Gump intentions. This is IMHO a grayish area, which I would like to investigate further. Perhaps it could be tested by setting a security policy for Ant which disallowed network connections. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: project version changes and Maven WAS: cvs commit: gump/project jakarta-commons.xml
On Tuesday 26 October 2004 17:50, Stefan Bodewig wrote: I'd really like to go down the track of having gump effectively run maven gump for a project, then use the generated descriptor instead. What is involved in that from the gump end? I assume since it happened for magic, it must be possible. It doesn't happen for Magic. The projects using Magic do the equivalent of maven gump and add the generated descriptor to Gump's metadata set IIUC. Yes, that is correct. If we had some better SVN support in Ant, the Gump descriptor would be generated and committed automatically with every build. Alternatively, Steve wanted Gump to ask Magic to generate the Gump descriptor before executing, i.e. before building the project models. An alternative to that, was we discussed to have a servlet generating it upon the http:// request, but that never took off either. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jms.xml jta.xml
On Tuesday 26 October 2004 18:51, Stefan Bodewig wrote: On 26 Oct 2004, [EMAIL PROTECTED] wrote: so I have added symbolic links to point to the official distros which exist in Gump as packages. For your symbolic links to work, you'll also need to add them as packages to the profile. If they link to installed packages, that is. The link is; ln -s jms.jar geronimo-jms-DEV.jar so it is only a Jar reference. Should work, right? Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
excalibur-configuration
Excalibur gang, Jakarta Turbine Fulcrum has a couple of projects that depends on the excalibur-configuration project, which doesn't exist anymore. What is the migration path for this artifact? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project jms.xml jta.xml
On Tuesday 26 October 2004 18:51, Stefan Bodewig wrote: On 26 Oct 2004, [EMAIL PROTECTED] wrote: so I have added symbolic links to point to the official distros which exist in Gump as packages. For your symbolic links to work, you'll also need to add them as packages to the profile. If they link to installed packages, that is. Well, well, well... Now I am starting to understand how some of this stuff works. :o) Thanks for the pointer Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The Kaffe instance and ant-bootstrap
Gang,
I have looked at the Kaffe instance and its inability to create the Ant
bootstrap.
The first level of problem is that the Kaffe compiler doesn't imply any source
files that are not specified, and that results in the immense number of
Cannot find class.
Unfortunately, all classes can not be specified either, as that requires
external dependencies, so I have gone through and class by class added what
is needed for the bootstrap to succeed this stage (see below).
I don't know if we should proceed by convincing Ant to introduce this to their
codebase, or we should maintain a separate bootstrap script.
WDYT?
Cheers
Niclas
P.S. After this passes, there are other issues further down in the bootstrap
script, but I haven't worked on those yet.
echo ... Compiling Ant Classes
${JAVAC} $BOOTJAVAC_OPTS -d ${CLASSDIR} \
${TOOLS}/bzip2/*.java \
${TOOLS}/tar/*.java \
${TOOLS}/zip/*.java \
${TOOLS}/ant/types/*.java \
${TOOLS}/ant/*.java \
${TOOLS}/ant/taskdefs/*.java \
${TOOLS}/ant/taskdefs/compilers/*.java \
${TOOLS}/ant/taskdefs/condition/*.java \
${TOOLS}/ant/dispatch/DispatchUtils.java \
${TOOLS}/ant/dispatch/Dispatchable.java \
${TOOLS}/ant/filters/ChainableReader.java \
${TOOLS}/ant/filters/ClassConstants.java \
${TOOLS}/ant/filters/EscapeUnicode.java \
${TOOLS}/ant/filters/ExpandProperties.java \
${TOOLS}/ant/filters/HeadFilter.java \
${TOOLS}/ant/filters/LineContains.java \
${TOOLS}/ant/filters/LineContainsRegExp.java \
${TOOLS}/ant/filters/PrefixLines.java \
${TOOLS}/ant/filters/ReplaceTokens.java \
${TOOLS}/ant/filters/StripJavaComments.java \
${TOOLS}/ant/filters/StripLineBreaks.java \
${TOOLS}/ant/filters/StripLineComments.java \
${TOOLS}/ant/filters/TabsToSpaces.java \
${TOOLS}/ant/filters/TailFilter.java \
${TOOLS}/ant/filters/TokenFilter.java \
${TOOLS}/ant/filters/util/ChainReaderHelper.java \
${TOOLS}/ant/helper/DefaultExecutor.java \
${TOOLS}/ant/helper/KeepGoingExecutor.java \
${TOOLS}/ant/helper/ProjectHelper2.java \
${TOOLS}/ant/helper/ProjectHelperImpl.java \
${TOOLS}/ant/helper/SingleCheckExecutor.java \
${TOOLS}/ant/input/DefaultInputHandler.java \
${TOOLS}/ant/input/InputHandler.java \
${TOOLS}/ant/input/InputRequest.java \
${TOOLS}/ant/input/MultipleChoiceInputRequest.java \
${TOOLS}/ant/launch/AntMain.java \
${TOOLS}/ant/taskdefs/email/EmailTask.java \
${TOOLS}/ant/taskdefs/email/Mailer.java \
${TOOLS}/ant/taskdefs/email/PlainMailer.java \
${TOOLS}/mail/MailMessage.java \
${TOOLS}/mail/ErrorInQuitException.java \
${TOOLS}/mail/SmtpResponseReader.java \
${TOOLS}/ant/taskdefs/rmic/KaffeRmic.java \
${TOOLS}/ant/taskdefs/rmic/ForkingSunRmic.java \
${TOOLS}/ant/taskdefs/rmic/WLRmic.java \
${TOOLS}/ant/taskdefs/rmic/SunRmic.java \
${TOOLS}/ant/taskdefs/rmic/RmicAdapter.java \
${TOOLS}/ant/taskdefs/rmic/RmicAdapterFactory.java \
${TOOLS}/ant/types/selectors/AndSelector.java \
${TOOLS}/ant/types/selectors/ContainsRegexpSelector.java \
${TOOLS}/ant/types/selectors/ContainsSelector.java \
${TOOLS}/ant/types/selectors/DateSelector.java \
${TOOLS}/ant/types/selectors/DependSelector.java \
${TOOLS}/ant/types/selectors/DepthSelector.java \
${TOOLS}/ant/types/selectors/DifferentSelector.java \
${TOOLS}/ant/types/selectors/ExtendSelector.java \
${TOOLS}/ant/types/selectors/ExtendFileSelector.java \
${TOOLS}/ant/types/selectors/FileSelector.java \
${TOOLS}/ant/types/selectors/FilenameSelector.java \
${TOOLS}/ant/types/selectors/MajoritySelector.java \
${TOOLS}/ant/types/selectors/NoneSelector.java \
${TOOLS}/ant/types/selectors/NotSelector.java \
${TOOLS}/ant/types/selectors/OrSelector.java \
${TOOLS}/ant/types/selectors/PresentSelector.java \
${TOOLS}/ant/types/selectors/SelectSelector.java \
${TOOLS}/ant/types/selectors/SelectorContainer.java \
${TOOLS}/ant/types/selectors/SelectorScanner.java \
${TOOLS}/ant/types/selectors/SelectorUtils.java \
${TOOLS}/ant/types/selectors/SizeSelector.java \
${TOOLS}/ant/types/selectors/TypeSelector.java \
${TOOLS}/ant/types/selectors/modifiedselector/ModifiedSelector.java \
${TOOLS}/ant/types/selectors/modifiedselector/Algorithm.java \
${TOOLS}/ant/types/selectors/modifiedselector/PropertiesfileCache.java \
${TOOLS}/ant/types/selectors/modifiedselector/DigestAlgorithm.java \
${TOOLS}/ant/types/selectors/modifiedselector/EqualComparator.java \
${TOOLS}/ant/types/selectors/modifiedselector/HashvalueAlgorithm.java \
${TOOLS}/ant/types/selectors/modifiedselector/ChecksumAlgorithm.java \
${TOOLS}/ant/util/ClasspathUtils.java \
${TOOLS}/ant/util/CollectionUtils.java \
${TOOLS}/ant/util/CompositeMapper.java \
${TOOLS}/ant/util/ConcatFileInputStream.java \
${TOOLS}/ant/util/ContainerMapper.java \
Re: cvs commit: gump/project jakarta-commons.xml
On Monday 25 October 2004 15:04, [EMAIL PROTECTED] wrote:
Now, is there a way to 'inject' the version into maven? otherwise we'll
have to continue updating these names as they projects change versions
One can access the POM as properties, such as ${pom.artifactId}, so there is a
small chance that setting pom.currentVersion would work, but I suspect that
the last-takes-precendence principle often used in Maven will prevail.
Cheers
Niclas
--
+--//---+
/ http://www.bali.ac/
/ http://niclas.hedhman.org /
+--//---+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem running Apache Gump...
On Sunday 24 October 2004 07:01, Adam R. B. Jack wrote: BTW: This looks like an instance of this bug: http://issues.apache.org/jira/browse/GUMP-85 Basically, somebody has (in the profile) mentioned a packaged project that doesn't exist in any module. Yes, I forgot that avalon-phoenix-dependencies were mentioned in the profile, when disabling Phoenix. Has been fixed. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Project excalibur-fortress-bean (in module excalibur) failed
On Sunday 24 October 2004 08:47, Gump Integration Build wrote: __ __ | \/ |__ _Apache__ ___ | | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ | |_| |_\__,_|\_/\___|_||_| v. 1.0 The build cannot continue because of the following unsatisfied dependencies: d-haven-event-1.0.3.jar d-haven-managed-pool-1.0.jar excalibur-lifecycle-impl-1.1.jar xerces-2.3.0.jar excalibur-fortress-bean-1.2.jar What is happening here? Maven thinks excalibur-fortress-bean depends on itself and tries to download it ?? I have checked the project.xml and I can't find anything wrong. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to refer to ws-xmlrpc as xmlrpc?
On Sunday 24 October 2004 19:52, Eric Pugh wrote: Hi Niclas.. I think the fix isn't working.. Not sure what is going on.. also, on a related note, I switched to javamail-1.3, but it doesn't seem to pick it up as well... The version doesn't matter. What matters is the match between the Maven artifactID and the JAR ID of javamail. I will spend some time on it and see what I can dig up. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to refer to ws-xmlrpc as xmlrpc?
On Sunday 24 October 2004 20:04, Niclas Hedhman wrote: On Sunday 24 October 2004 19:52, Eric Pugh wrote: Hi Niclas.. I think the fix isn't working.. Not sure what is going on.. also, on a related note, I switched to javamail-1.3, but it doesn't seem to pick it up as well... The version doesn't matter. What matters is the match between the Maven artifactID and the JAR ID of javamail. I will spend some time on it and see what I can dig up. Ok, I think I have a solution in hand. Next run of Gump will be 3.5 hours from now, so it will take 6 hours or so before we know. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to refer to ws-xmlrpc as xmlrpc?
On Thursday 21 October 2004 05:56, Eric Pugh wrote: Okay.. Sorry for being dense but.. Where do I put this: maven.jar.artifactID = path to Jar For all normal cases; You don't. It is done in the maven.py script. I am not even sure it will work for non-normal cases, and if a proper classpath can be picked up at all, but I think IF it doesn, it would be something like; maven goal=jar basedir=whatever property name=maven.jar.abc project=abc-project id=IdOfAJar / /maven But I am not sure... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] move metadata to SVN
On Thursday 21 October 2004 12:34, Stefano Mazzocchi wrote: place your vote. I don't know who is eligable for voting in Gump, but I guess it is all the ASF committers... so here is my; +1 -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Re: NoopInstrumentManager has moved incompatibly
-- Forwarded Message -- Subject: Re: NoopInstrumentManager has moved incompatibly Date: Thursday 21 October 2004 15:15 From: Peter Donald [EMAIL PROTECTED] To: Excalibur Developers List [EMAIL PROTECTED] Niclas Hedhman wrote: Question 1; Does James run out-of-the-box on Loom? James should run out of the box *IF* a few extra jars are added to the deployment archive. Question 2; Can/should we add Loom to the be built from source by Gump? It is possible but it may not add any value as the only part that james would directly depend upon is the phoenix-api jar. Loom uses the last release of this from avalon which was probably the release of a few years ago. It would be better to archive off phoenix, but maybe keep the phoenix-api jar dependency around or something. NFI as I haven't looked at the source for ages! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to refer to ws-xmlrpc as xmlrpc?
On Thursday 21 October 2004 16:57, Eric Pugh wrote: So, I add this: property name=maven.jar.bsf project=jakarta-bsf id=bsf.jar / property name=maven.jar.xmlrpc project=ws-xmlrpc id=xmlrpc.jar No, the id refers to the declared id in the jar of the project (and I am not sure what that defaults to, btu I suspect not what you wrote). The two projects you are referring to, are both declaring only one jar, in which case the id= above not necessary. I have committed that change. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Re: NoopInstrumentManager has moved incompatibly
On Thursday 21 October 2004 21:34, Stefan Bodewig wrote: On Thu, 21 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: From: Peter Donald [EMAIL PROTECTED] Niclas Hedhman wrote: Question 1; Does James run out-of-the-box on Loom? James should run out of the box *IF* a few extra jars are added to the deployment archive. Loom contains org.apache packages? IIRC, I have seen PeterD change them all to codehaus ones. And as Stephen mentions, nothing in James depend on those. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Last /public/ run...
This Gump run is complete. It started at Wed, 20 Oct 2004 21:01:08 (PDT) and ended at Wed, 20 Oct 2004 23:40:05 (PDT). If I count correctly, this is many starts ago. The run after this one should have been another /public/ run. Anybody knows why the cron jobs have stopped? Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Favor for the Gump Project
On Wednesday 20 October 2004 10:03, Stefano Mazzocchi wrote: Greg Wilkins wrote: No problem applying that patch, as it just makes sealing configurable. Not only does he introduce the property, but also set it to 'false' by default in the ant.properties file. The run at 0700 UTC steal exposed the same problem. So let's see what happen with the one starting at 1000 UTC, since I have now verified that Greg's change is in the source. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please install javamail-1.3.1.jar into Gump
On Wednesday 20 October 2004 17:31, Eric Pugh wrote: Hi, Quite a few of the Jakarta Turbine Fulcrum components use the javamail-1.3.1.jar version of JavaMail. Currently Gump has javamail-1.3 installed. Can we have this dependency upgraded? This will remove the last obstacle to our components compiling under Gump. This is not about 1.3 vs 1.3.1, never was... Please proceed and change to whatever version you like. Now, the problem is about the 'exposure' of the Jar's from their names on the Brutus filesystem, vs the name expected in your projects. Stefano gave me heads up earlier that he is tackling this in a generic fashion, since it won't scale if we go in and ask for changes in each project. That means that we will be able to declare in the Gump descriptor that abc.jar is used for an def-x.y.z.jar by Maven (and others), so that in the overrides file, maven.jar.override = on maven.jar.abc = /usr/local/./javamail/mail.jar is generated. This will solve all projects with a similar situation and allowing all the existing ant-wrappers for Maven projects to go away. So, just hang in tight, and the problem will be solved at Gump's end. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Re: Please install javamail-1.3.1.jar into Gump
-- Forwarded Message -- Subject: Re: Please install javamail-1.3.1.jar into Gump Date: Wednesday 20 October 2004 18:07 From: Henning P. Schmiedehausen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Niclas Hedhman [EMAIL PROTECTED] writes: That means that we will be able to declare in the Gump descriptor that abc.jar is used for an def-x.y.z.jar by Maven (and others), so that in the overrides file, maven.jar.override = on maven.jar.abc = /usr/local/./javamail/mail.jar Could you please explain what this means exactly for a project? Does it that mean, that I cannot rely whether the projects are run by the Gump with the jar versions that have been specified in project.xml? How does that scale? Consider changes like commons-collections 3.0 vs. 3.1 or commons-lang changes? Or commons-configuration rc1 vs. rc2 What significance has a continous integration test if it does not test the environment specified for the application? is generated. This will solve all projects with a similar situation and allowing all the existing ant-wrappers for Maven projects to go away. This introduces just another layer of gotchas The whole override shebang was a really bad idea when Jason introduced it into maven and it hasn't improved a bit yet. Sort of bolted on to scratch an itch. If I want to test vs. javamail-1.3.1.jar or torque-3.1.1-rc3.jar then I do want against this jar. Not against some dependency that Gump decide to swap for javamail-1.3.jar or torque-3.1.jar. This simply makes no sense to me. One of the few really good things that Jason did when building the artifact code is, that he forced jars to have a version. It was a really stupid idea from Sun to release mail.jar. Even mail-1.3.1.jar would have been better. Renaming sthese jars is IMHO a good thing that maven has enforced. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please install javamail-1.3.1.jar into Gump
On Wednesday 20 October 2004 18:07, Henning P. Schmiedehausen wrote: Niclas Hedhman [EMAIL PROTECTED] writes: That means that we will be able to declare in the Gump descriptor that abc.jar is used for an def-x.y.z.jar by Maven (and others), so that in the overrides file, maven.jar.override = on maven.jar.abc = /usr/local/./javamail/mail.jar Could you please explain what this means exactly for a project? snip content=elaboration / This is probably a very interesting observation, which has to do about the purpose of Gump. Gump does not exist to make sure your system/project work. That is your own responsibility. Gump's purpose is to ensure that a source code change YOU (in anonymous sense) make doesn't aversely affect someone else, and if it does it should be captured and everyone involved should be notified about it ASAP, before any releases are being made. That means that building against the declared versions are not an option. That doesn't provide a solution to the purpose. We need to build against either the latest known sources, and for generational shifts (i.e. compatibility is not maintained) we have to introduce separate projects for them, and in many cases both generations will be maintained by those projects over a limited period of time, e.g. tomcat. I hope this clarifies why it is not in Gump's interest to use the versions (generations, yes, not versions) that you declare for your project, but the latest/greatest non-released stuff. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Re: NoopInstrumentManager has moved incompatibly
So, Phoenix won't build completely from source. So either * package Phoenix as an installed package * package the older excalibur instrument API in a package * remove Phoenix and projects that depends on Phoenix, * introduce Loom as a Phoenix replacement, * other? Cheers Niclas -- Forwarded Message -- Subject: Re: NoopInstrumentManager has moved incompatibly Date: Wednesday 20 October 2004 17:07 From: Peter Donald [EMAIL PROTECTED] To: Excalibur Developers List [EMAIL PROTECTED] Niclas Hedhman wrote: On Sunday 17 October 2004 10:41, Niclas Hedhman wrote: Leif, You have at some point made an incompatible change, by moving the NoopInstrumentManager to a different package. Maybe this got buried in too many Gump messages. If this is the change I think it was then the change was made close to 2 years ago and given that phoenix was no longer maintained, it ceased to compile. I would axe phoenix from gump if possible otherwise you can just depend on specific static version of instrument as a jar dependency. -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please install javamail-1.3.1.jar into Gump
On Wednesday 20 October 2004 23:44, Stefano Mazzocchi wrote: What is the maven ID for the mail.jar package? That is the entire problem; There is none. Each project has been pushing their own for each of the non-distributables, mostly from Sun. I have asked Brett (of Maven) to establish a recommended list of group/artifact for all the stuff that can not be placed on the central repositories. As it stands, I only know of Avalon LogKit and Fulcrum, and they don't use the same IDs. :o( My personal opinion is that everything from Sun is thrown into a single group, and each Jar keeps its name, but with the added version. Unfortunately, this is not something used anywhere. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to refer to ws-xmlrpc as xmlrpc?
On Wednesday 20 October 2004 23:55, Eric Pugh wrote: So.. From looking at the third reference, and then looking at some examples, what I want is this: depend property=xmlrpc.jar project=ws-xmlrpc/ And then when Maven runs, it will look for xmlrpc.jar. So, something is telling Maven that it is NOT looking for xmlrpc-1.1.jar (which is what is defined in project.xml) but instead to look for xmlrpc.jar. And the depend property=xmlrpc.jar project=ws-xmlrpc/ says go look at this project for what you need.. Is this correct? I don't think so. AFAIK, the only properties that Maven cares about are of the format; maven.jar.artifactID = path to Jar Cheers Niclas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Please put in gump repo the tagishauth-1.0.3.jar
On Tuesday 19 October 2004 19:42, Stefan Bodewig wrote: The jars you list come from four different Opensymphony projects. I can't find OSUser on opensymphony.org at all, BTW. We might want to build all of them from source one day, so they should be separate Gump projects instead of one big one. This is my fault. I recommended the four Jars in one project, simply due to I thought it was more convenient with 1 dir with 4 Jars instead of 4 dirs with 1 jar each... Either way can do, no technical obstacles. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project excalibur.xml xml-xalan.xml
On Tuesday 19 October 2004 19:19, [EMAIL PROTECTED] wrote: bodewig 2004/10/19 04:19:55 Modified:project excalibur.xml xml-xalan.xml Log: having the same jar with two ids seems to drop one id leading to the breakage for jstl and others You will need to modify maven.py as well, since Artifacts with type=boot seems to not be generating the maven.jar.xalan= override, in which case you get a Artifact not found. I have been trying before with manual property declarations for that, but unable to succeed. Cheers Niclas-- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: gump/project excalibur.xml xml-xalan.xml
On Tuesday 19 October 2004 22:03, Stefan Bodewig wrote: When have you last tried to use type=boot together with maven jar overrides? try?? If you get excalibur-logger back working, then Excalibur will break on excalibur-xmlutil, where I found this symptom. Xalan is (was) in the bootclasspath, yet Maven complained of missing dependency. I don't know where to find the overrides file, or even if I have access to it. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Proposal] Removal of xerces1
Gang, Only xerces-dist1 (which nothing depends on) depends on xerces1. Xerces-1, doesn't build in JDK1.5. Is it time to remove it from the descriptors? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDK1.5 warning
We have started to trial with JDK1.5 in Gump. It won't be soon for it to become the official build platform, nor nagging you about it. However, I think it is time to slowly reporting problems found, to the respective camps, for them to take a look at it. http://brutus.apache.org/gump/jdk15/xml-crimson/xml-crimson/gump_work/build_xml-crimson_xml-crimson.html I believe this to be mostly a DOM3 (will they never learn?) issue, and not sure if there is anything that can be done about it, without breaking compatibility with JDK1.4 builds. Open for any suggestions. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Please remove enum as variable name.
We have started to trial with JDK1.5 in Gump. It won't be soon for it to become the official build platform, nor nagging you about it. However, I think it is time to slowly reporting problems found, to the respective camps, for them to take a look at it. http://brutus.apache.org/gump/jdk15/logging-log4j-12/logging-log4j-12/gump_work/build_logging-log4j-12_logging-log4j-12.html This is the Log4J 1.2 package ( I haven't checked 1.3 yet), which uses the enum variable name that is not compatible in JDK1.5. Is it possible for you guys to; 1. remove this in the 1.2 branch?? 2. check if it is present in the 1.3 development? It would make us very happy if it could be arranged. Thanks Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.1 still hanging about??
I am looking at this, and it seems that there is a binary incompatibility of JDK1.1 vs JDK1.5 classes involving the JDK1.5 run of Gump for the jakarta-commons-lang package. Details; http://brutus.apache.org/gump/jdk15/jakarta-commons/commons-lang/gump_work/build_jakarta-commons_commons-lang.html Anyone has any clue what this is? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Removal of xerces1
On Tuesday 19 October 2004 06:26, Adam R. B. Jack wrote: BTW: What was the outcome xerces (Gump name) != xerces2 (Maven name). Would we chose this time to make a change there? You mean xalan? I don't think xerces has been an issue. Or was there? Xalan has been altered, but there is a bootstrap classpath problem associated with the maven.py. xalan specifies its Jars to be type=boot, in which case the maven.jar.id is not created. That creates problems when a Maven project declares a dependency on xalan. And my Python skills == none... And don't hope that will change (I am allergic to whitespace sensitive stuff) Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RT] Selling Gump...
I think we need a major re-think about what Gump is and how it is perceived among our peers. Gump - The Apache Continous Integration Service. Keyword; Service. We need to get rid of the nags in their current form. They are probably too intrusive and irritating. Instead of providing value to the projects, it creates at best an 'ignorance' of those messages. I think any project that are somewhat downstream, is no longer bothering about the Gump messages. I am not entirely sure what should be done, since the best solution I can think of is probably not applicable, and that is that whenever a commit is made, the project and all dependees are built, and if it fails, the 'notification' goes to the committer. We don't have enough CPU resources for such a brute approach. But I think we need to somehow tie the 'commits' into the build loop, so what when a regression occurs, a list of commits that may have affected that build can be reviewed easily. And secondly, let the Gump folks redirect the notifications manually, to where we believe them to belong. WDYT? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant style task is failing
On Saturday 16 October 2004 14:41, Bill Barker wrote: The projects jakarta-tomcat-catalina and jakarta-tomcat-4.0 are failing because the style task doesn't work (java.lang.NoClassDefFoundError: org/apache/xml/serializer/OutputPropertiesFactory). It looks like the problem is that xalan's serializer.jar is in the CLASSPATH, but xalan-unbundled.jar is in the bootclasspath. The serializer classes has been removed from the xalan-unbundled into a the serializer.jar. H... Looking closer, xalan-unbundled.jar ends up in the bootstrap classloader, whereas the serializer is in the system classloader. Wonder if that is significant. Does anybody have an idea for a solution? I am working on it. But any ideas are welcome, and the problem is across MANY projects... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Blood, More Blood, the Bloodies Day in Gump history...
Gang, I blew it... One 2 too much, and a missing / is the total cause of the problems we are seeing now... I told Steve, It is so sensitive. Like if running out of paper in an airplane toilet, would make it crash and 300 dead. Well, well Won't sleep until it is back to the 80+% I had before. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yes, I broke the Xalan build
On Saturday 16 October 2004 23:07, Brian Minchau wrote: So for those who are fixing the classpaths of the GUMP build you need to include ./java/build/serializer or ./java/build/serializer.jar in the classpath. All taken care of. Although it has to go into the bootclasspath, which took me a while to figure out. FYI, Gump has changed the xml-xalan2 Gump ID to xalan since we need it to match with Maven IDs. The xml-xalan2 name will remain for a while for compatibility, and I have changed all the affected projects that are inside the Gump CVS. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Friday 15 October 2004 19:02, Stephen McConnell wrote: Can we just put a symlink in place that links merlin-unit to avalon-merlin-unit?. ?? I think the answer lies in the fact that merlin-unit has changed name to avalon-merlin-unit, and the Magic descriptor should provide a compatibility link. i.e. An empty project in index.xml that only creates the dummy Gump project linking the output of avalon-merlin-unit to a merlin-unit project. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Friday 15 October 2004 19:10, Eric Pugh wrote: I am a little confused.. Why is the behavior of avalon-merlin-unit special/more difficult then any other dependency? That is due to a name change. merlin-unit is needed in your Maven descriptor since that has been released before. avalon-merlin-unit is the new name, and that is the Gump descriptor generated. So, when you add depend project=avalon-merlin-unit/ you will not get the proper override for the Maven descriptor, and Maven will report that merlin-unit-x-x.jar can not be found. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Re: Yes, I broke the Xalan build
Didn't notice the incorrect mailing list address at first. -- Forwarded Message -- Subject: Re: Yes, I broke the Xalan build Date: Saturday 16 October 2004 01:17 From: Mohammad Isac Niclas bin Abdullah [EMAIL PROTECTED] To: Brian Minchau [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] On Friday 15 October 2004 23:44, Brian Minchau wrote: Niclas, I was the person who changed the build of some classes in Xalan. No problems, except that the xml-xalan CVS checkout takes a hell of a long time for me, to get to see what had happened :o) OTOH, first time I ever built it from source myself... The reason for work is that, that directory will be added to the classpath upon ant start. dist-xalan2 breaks for similar reason I guess, and I think I need to add a depend on the serializer output Jar. Will fix that shortly... Cheers Niclas -- +-//---+ | http://www.bali.ac | | http://niclas.hedhman.org | +--//--+ --- -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On Thursday 14 October 2004 14:38, Stefan Bodewig wrote: On Thu, 14 Oct 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Instead, I suggest that we take the prettyprinter.jar from the xdoclet CVS and make it into an installed package in Gump. Just create a project for it inside xdoclet's descriptor. Name it xdoclet-pretty or something. No need to turn it into a full installed package (which would require access to Brutus to update) IMHO. Done. But not entirely sure if it will work. Review appreciated. + project name=xdoclet-prettyprinter +jar name=lib/prettyprinter.jar/ + /project -depend project=jrefactory-pretty/ +depend project=xdoclet-prettyprinter/ Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Thursday 14 October 2004 17:37, Eric Pugh wrote: merlin-unit-3.3.0.jar avalon-meta-plugin-1.4.0.jar For Maven builds; groupIdavalon/avalon-meta/groupId artifactIdavalon-meta-plugin/artifactId groupIdavalon/merlin/groupId artifactIdmerlin-unit/artifactId respectively, AND requires http://www.apache.org/dist/ as a Maven repository. I am not sure why it doesn't synchronize to ibiblio.org/maven. I thought that was automatic. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Thursday 14 October 2004 17:37, Eric Pugh wrote: As far as the error on merlin-unit, I think that in the jakarta-turbine-fulcrum.xml file we depend on avalon-merlin-unit however, in the avalon.xml file it is defined as merlin-unit, so I think I should change that to merlin-unit: depend project=avalon-merlin-unit/ to depend project=merlin-unit/ :o) No, the project here refers to the name within Gump, but I think that the following is needed; depend property=maven.jar.merlin-unit project=avalon-merlin-unit/ Brett, do you have any insight in this?? Steve? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some progress on Fulcrum Component Builds!
On Thursday 14 October 2004 18:14, Brett Porter wrote: groupIdavalon/avalon-meta/groupId artifactIdavalon-meta-plugin/artifactId groupIdavalon/merlin/groupId artifactIdmerlin-unit/artifactId why isn't this just avalon-meta and merlin for the group? If it is so you can leverage dist/, that's not correct (see below). /dist/java-repository/ syncs to ibiblio, which contains: http://www.apache.org/dist/java-repository/avalon-meta/plugins/avalon-meta- plugin-1.4.0.jar http://www.apache.org/dist/java-repository/merlin/jars/merlin-unit-3.3.0.ja r Ok. I was WRONG. Somewhere there is a misconception... However, I assume this is just for building with Maven regularly, as under gump it is all offline. Well, Eric is having problem with his local build, so we are trying to solve two issues at the same time. Thanks for the rectification. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependence on mysql jdbc driver bogus?
On Thursday 14 October 2004 22:00, Berin Loritsch wrote: Stefano Mazzocchi wrote: excalibur-datasource fails to build because it depends on mm-mysql but doing a grep -r mysql . in that directory doesn't yield anything. I suspect it's a bogus dependency in their POM. Thoughts? Niclas discovered the same thing. I think he committed the change, or at least has a patch ready. I got his message something like 5 minutes ago. Steve committed it. I don't have commit rights in Excalibur. I am just trying to get Excalibur work with Gump, since noone else is interested enough... Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
