Confluence email notifications (was: Board Report Draft)

[sebb]

On Sun, 9 Jun 2019 at 16:37, Stefan Bodewig  wrote:



> PS: if anybody knows how to enable email notifications in Confluence I'd
> be grateful if you could just cast the necessary spells.

You can personally subscribe to changes.
But if you want changes sent to a list@gump.a.o, this requires extra work:

https://issues.apache.org/jira/browse/INFRA-18107

Have a look at dev@tomcat and see if the results are what you want.

S.

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Cron /usr/bin/find /tmp -type f -ctime +6 | /usr/bin/xargs -r /bin/rm > /dev/null 2>&1

[sebb]

I got the redirects wrong.

I think it should be:

/usr/bin/find /tmp -type f -ctime +6 2>/dev/null | /usr/bin/xargs -r /bin/rm

i.e. drop error reports from find, but keep any other output (rm
should be silent unless there is an error)


On Fri, 31 May 2019 at 14:52, Mark Thomas  wrote:
>
> On 31/05/2019 14:36, Stefan Bodewig wrote:
> > On 2019-05-31, Mark Thomas wrote:
> >
> >> On 31/05/2019 13:22, Stefan Bodewig wrote:
> >>> On 2019-05-31, sebb wrote:
> >
> >>>> The command:
> >
> >>>> /usr/bin/find /tmp -type f -ctime +6 | /usr/bin/xargs -r /bin/rm >
> >>>> /dev/null 2>&1
> >
> >>>> should perhaps be
> >
> >>>> /usr/bin/find /tmp -type f -ctime +6 > /dev/null 2>&1 | /usr/bin/xargs
> >>>> -r /bin/rm
> >
> >>>> or maybe
> >
> >>>> { /usr/bin/find /tmp -type f -ctime +6 | /usr/bin/xargs -r /bin/rm } >
> >>>> /dev/null 2>&1
> >
> >>> Probably,
> >
> >>> Infra is in the process of setting up a new VM for us and the mails will
> >>> keep coming in until somebody of us has time to complete the post-puppet
> >>> setup - which may be a few weeks to be honest.
> >
> >>> https://github.com/apache/infrastructure-puppet/blob/deployment/modules/gump_server/manifests/cronjobs.pp
> >
> >>> contains what would need to be fixed IIRC.
> >
> >> I can find some time. To be clear the issue is that the cron jobs aren't
> >> quite defined correctly and those definitions need to be fixed?
> >
> > *This* problem, yes. There are more of them. :-)
> >
> > Basically we need to perform the steps listed in
> > https://cwiki.apache.org/confluence/display/GUMP/VmgumpConfig after
> > "Puppet" and before
> > "https://cwiki.apache.org/confluence/display/GUMP/VmgumpConfig;
> >
> > and I'm afraid we are now using Python 3 but haven't verified that -
> > which might require changes to the code base.
> >
> > Also some of the Ubuntu packages defined as dependencies in Puppet, in
> > particular those for Mono have probably failed to install.
> >
> >> And the fixes need to be made in the file quote above and then Puppet
> >> will deploy the updated cron jobs to our new VM?
> >
> > Here I am guessing. This is (part of) the Puppet manifest that was used
> > to set up vmgump3. I believe it has been used to set up the new
> > machine.
> >
> > Stefan
>
> OK. I'll see what I can do. I'll update that wiki page as I go.
>
> Mark
>
> -
> To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
> For additional commands, e-mail: general-h...@gump.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Cron /usr/bin/find /tmp -type f -ctime +6 | /usr/bin/xargs -r /bin/rm > /dev/null 2>&1

[sebb]

The command:

/usr/bin/find /tmp -type f -ctime +6 | /usr/bin/xargs -r /bin/rm >
/dev/null 2>&1

should perhaps be

/usr/bin/find /tmp -type f -ctime +6 > /dev/null 2>&1 | /usr/bin/xargs
-r /bin/rm

or maybe

{ /usr/bin/find /tmp -type f -ctime +6 | /usr/bin/xargs -r /bin/rm } >
/dev/null 2>&1

On Fri, 31 May 2019 at 01:00, Cron Daemon  wrote:
>
> /usr/bin/find: ‘/tmp/netplan_r7snggmq’: Permission denied
> /usr/bin/find: ‘/tmp/netplan_g8j2m19z’: Permission denied
> /usr/bin/find: ‘/tmp/tmp.mqEIz4DoC1’: Permission denied
> /usr/bin/find: ‘/tmp/tmpd7wh86x7’: Permission denied
> /usr/bin/find: ‘/tmp/netplan_gncfwvky’: Permission denied
> /usr/bin/find: ‘/tmp/netplan_d3sx1bq7’: Permission denied
> /usr/bin/find: ‘/tmp/netplan_8tssf_z6’: Permission denied
> /usr/bin/find: ‘/tmp/tmp8z9c7dfj’: Permission denied
> /usr/bin/find: ‘/tmp/tmpfji1fu0x’: Permission denied
> /usr/bin/find: ‘/tmp/netplan_edhtik2z’: Permission denied
> /usr/bin/find: ‘/tmp/netplan_k423bbnz’: Permission denied
> /usr/bin/find: 
> ‘/tmp/systemd-private-d9c0d36b941943149a69afd270a66f89-apache2.service-ucphCf’:
>  Permission denied
> /usr/bin/find: ‘/tmp/netplan_7w1rmyzr’: Permission denied
> /usr/bin/find: ‘/tmp/ssh-6AcJaZKfNZ’: Permission denied
> /usr/bin/find: ‘/tmp/netplan_05tr3ns3’: Permission denied
> /usr/bin/find: 
> ‘/tmp/systemd-private-d9c0d36b941943149a69afd270a66f89-systemd-timesyncd.service-CH9LeL’:
>  Permission denied
> /usr/bin/find: 
> ‘/tmp/systemd-private-d9c0d36b941943149a69afd270a66f89-systemd-resolved.service-qNbXiK’:
>  Permission denied
> /usr/bin/find: 
> ‘/tmp/systemd-private-d9c0d36b941943149a69afd270a66f89-tomcat9.service-8Bhz9I’:
>  Permission denied
>
> -
> To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
> For additional commands, e-mail: general-h...@gump.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r1817993 - /gump/metadata/project/tomcat-trunk.xml

[sebb]

On 14 December 2017 at 15:20, Mark Thomas  wrote:
> On 14/12/17 13:18, Konstantin Kolinko wrote:
>> Hi, Mark!
>>
>> To dev@tomcat, cc: general@gump.
>>
>>
>> The result of this change is that Gump building Tomcat downloads
>> tar.gz for Commons-Daemon from mirrors.
>
> Drat. That wasn't the intention at all.
>
> 
>
>> The "mvn package" command used by Gump does not build the src.tar.gz file.
>>
>> The file can be built by "mvn assembly:single" command, [4]
>> but HOWTO-RELEASE.txt file does not mention it so I wonder what is
>> actually used by Commons Daemon here.
>
> The command 'mvn deploy -Prelease' creates it. I suspect that isn't
> appropriate for Gump.

FTR:

You can add the following options to deploy to target/deploy and not
sign the artifacts:

-Ptest-deploy -Dgpg.skip

Documented here:

http://commons.apache.org/releases/prepare.html#Create_the_Release_Candidate

>> So this can be fixed by updating Gump configuration for commons-daemon to do
>>  and
>> >  id="native-distro" />
>>
>>
>> Alternatively, a question is whether the "deploy" target in Tomcat
>> actually has a need to copy the *.tar.gz files to CATALINA_HOME/bin/.
>> Those source file are needed when redistributing Tomcat, but they are
>> not actually needed when running it.
>
> Good point.
>
> The Windows binaries are only copied to /bin for the dist-static target.
> I can't see a reason not to treat the *.tar.gz src files the same way.
>
> Mark
>
> -
> To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
> For additional commands, e-mail: general-h...@gump.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: [Gump Wiki] Update of Drafts/BoardReports/20140618 by StefanBodewig

[sebb]

On 8 June 2014 12:57, Apache Wiki wikidi...@apache.org wrote:
 Dear Wiki user,

 You have subscribed to a wiki page or wiki category on Gump Wiki for change 
 notification.

 The Drafts/BoardReports/20140618 page has been changed by StefanBodewig:
 https://wiki.apache.org/gump/Drafts/BoardReports/20140618

 New page:
 Apache Gump is a cross-project continuous integration server.  Gump's 
 intention isn't so much to be a CI server but rather a vehicle that makes 
 people look beyond their project's boundaries and helps the projects to 
 collaborate.

 Gump is written in Python and supports several build tools and version 
 control systems.  The Apache installation of Gump builds ASF as well as 
 non-ASF projects and their dependencies.  It started in the Java part of the 
 foundation but also builds projects like APR, HTTPd and XMLUnit.NET.

 == Summary ==
 Gump seems to create useful results for the few projects that use it.  Ant 
 decided to switch from svn to git which might require some real coding work 
 to be done.

 == Releases ==
 Gump has never done any releases.  One reason for this is that the ASF 
 installations of Gump work on the latest code base almost all of the time 
 following its integrate everything continuously philosophy.

 == Activity ==
 Ant migrated most if its codebases from svn to git.  When Gump switched to 
 use the git location we had to learn the ASF's https git service was not 
 compatible with git 1.7.x which still is the latest version available as 
 package for Ubuntu 10.04 (which powers vmgump).  A self-compiled git 2.0 on 
 vmgump solved the problem.

s/most if its/most of its/

 While Gump caught up with the change for Ant itself, the Antlib and Ivy 
 builds are still using the stale svn uris.  The Ant project is currently 
 pondering the idea of using git submodules for the Antlibs projects, these 
 are not supported by Gump, yet, which may require some changes in the git 
 integration.

 == Changes to the Roster ==
 All ASF committers have write access to the metadata that configure the ASF 
 installations.

 No new committers to the code base, no changes to the PMC.  The most recent 
 addition to the PMC was in December 2006 when we added Sander Temme.

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Your Gump Build(s)

[sebb]

On 24 June 2013 14:58, Dominik Psenner dpsen...@apache.org wrote:
 Hey Stefan,

 Talking for log4net, yes. We use Gump.

 See: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/

 Bringing up the discussion again. Is it possible to publish nightly builds
 using gump? It has been requested several times and it would be a lot easier
 than setting up/migrate to a second build system.

Sorry, but I don't think that's a good idea.

Snapshot builds should be done using the same dependencies as the
release build would use.

Also publishing builds will increase the Gump run time, which is
already very long.

 Cheers

-Ursprüngliche Nachricht-
Von: Stefan Bodewig [mailto:bode...@apache.org]
Gesendet: Montag, 24. Juni 2013 15:21
An: d...@apr.apache.org; d...@activemq.apache.org; d...@ant.apache.org;
d...@camel.apache.org; d...@cocoon.apache.org;
d...@commons.apache.org; d...@creadur.apache.org;
d...@directory.apache.org; d...@forrest.apache.org; d...@hc.apache.org;
d...@httpd.apache.org; d...@jmeter.apache.org;
gene...@james.apache.org; d...@lenya.apache.org;
gene...@logging.apache.org; d...@lucene.apache.org; d...@poi.apache.org;
bridges-...@portals.apache.org; pluto-...@portals.apache.org;
d...@tapestry.apache.org; d...@tika.apache.org; d...@tomcat.apache.org;
d...@turbine.apache.org; d...@velocity.apache.org; d...@ws.apache.org;
gene...@xmlgraphics.apache.org; gene...@xerces.apache.org;
d...@xalan.apache.org; d...@pdfbox.apache.org
Cc: general@gump.apache.org
Betreff: Your Gump Build(s)

Dear Community

Apache Gump builds some of your projects and it is quite possible you
don't know or have by now forgotten about it.

More than half a year ago a technical problem has forced us to turn off
emails on build failures as we would have been sending out lots of false
alarms.

Before we re-enable emails we'd like to know whether you are still
interested in the service Gump provides, so please tell us. :-)

Metadata for many projects have been neglected for a long time and it is
quite possible they'd need some love for results to be meaningful.  All
Apache committers have write access to Gump's metadata.

In case you don't know what this Gump stuff is about:

Apache Gump builds the full stack of the latest commits of software in
order to ensure integrity over releases.  Build failures surface API
discontinuities between projects before they impact releases, and Gump's
e-mail notifications hope to promote the conversations between teams to
resolve those discontinuities.

When responding to this mail please shorten the CC list as appropriate.

Cheers

Stefan

 on behalf of the Gump PMC


 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: strange DATE in Gump

[sebb]

On 25 December 2012 06:36, Stefan Bodewig bode...@apache.org wrote:
 On 2012-12-21, David Crossley wrote:

 While trying to debug a Gump run, i noticed some jars in the classpath
 with strange filenames, e.g. ant-contrib-20122012.jar
 I presume that that is expanded from the @@DATE@@ in project/ant-contrib.xml

 Should that be MMDD so 20121220?

 Right now @@DATE@@ on http://vmgump.apache.org/gump/public/index.html
 says 24122012 which looks strange for most people[1].  I recall
 wondering why it is so several times but never bothered to change it.

 It's very unlikely any harm could be done if @@DATE@@ was changed to a
 more common format.

 Stefan

 [1] for Germans the format is what you'd use when writing down the
 current date.  I don't recall writing that code, though.

DDMM is also used in the UK; it's mainly (only?) the US who use MMDD

MMDD format would be much clearer; even better might be -MM-DD
as that would make the format obvious.

[MM cannot be larger than 12, so a date in MMDD format cannot be
confused with a date in DDMM or MMDD format unless we expect
dates from the 13th Century or earlier! - but it's easier to read with
separators]

And of course -MM-DD and MMDD naturally sort chronologically.

[I've not wriiten any Gump code]

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Fwd: [GUMP@vmgump]: Project commons-functor (in module apache-commons) failed

[sebb]

I moved the functor build from sandbox to proper, and since then it
has not built.

It looks like Gump is checking out the code from
commons/proper/functor instead of commons/proper/functor/trunks but I
cannot work out where that is defined; the meta-data looks OK compared
with other entries in commons-proper.

Any idea?
-- Forwarded message --
From: Gump iss...@commons.apache.org
Date: 22 September 2011 08:50
Subject: [GUMP@vmgump]: Project commons-functor (in module
apache-commons) failed
To: d...@commons.apache.org


To whom it may engage...

This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at general@gump.apache.org.

Project commons-functor has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
   - commons-functor :  Functor: Function Objects


Full details are available at:
   
http://vmgump.apache.org/gump/public/apache-commons/commons-functor/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages)
were provided:
 -DEBUG- Sole jar output [commons-functor-1.0-SNAPSHOT.jar] identifier
set to project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/functor/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-functor/gump_work/build_apache-commons_commons-functor.html
Work Name: build_apache-commons_commons-functor (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings
/srv/gump/public/workspace/apache-commons/functor/gump_mvn_settings.xml
package
[Working Directory: /srv/gump/public/workspace/apache-commons/functor]
M2_HOME: /opt/maven2
-
[INFO] Scanning for projects...
[INFO] 
[INFO] Building Maven Default Project
[INFO]    task-segment: [package]
[INFO] 
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Cannot execute mojo: resources. It requires a project with an
existing pom.xml, but the build is not using one.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 second
[INFO] Finished at: Thu Sep 22 07:50:17 UTC 2011
[INFO] Final Memory: 4M/15M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-functor/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-functor/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 05000622092011, vmgump.apache.org:vmgump:05000622092011
Gump E-mail Identifier (unique within run) #14.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Fwd: [GUMP@vmgump]: Project commons-functor (in module apache-commons) failed

[sebb]

On 22 September 2011 10:42, Stefan Bodewig bode...@apache.org wrote:
 On 2011-09-22, sebb wrote:

 I moved the functor build from sandbox to proper,

 Thank you.

 and since then it has not built.

 It looks like Gump is checking out the code from
 commons/proper/functor instead of commons/proper/functor/trunks but I
 cannot work out where that is defined; the meta-data looks OK compared
 with other entries in commons-proper.

 Gump is checking out trunks-proper and the svn:externals on it for
 functor has been wrong (pointed to functor rather than functor/trunk).
 Should already be fixed.

I checked the externals, and could not see the error - did not notice
you had recently fixed it; thanks!

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Help needed with ASF Branding Requirements

[sebb]

On 4 June 2011 06:32, Stefan Bodewig bode...@apache.org wrote:
 On 2011-06-03, Stefan Bodewig wrote:

 Right now we have Apache Gump is the oldest continuous integration tool
 of the Apache Sofware Foundation. and I propose to change it to The
 Apache Gump continuous integration tool was the first one used at the
 Apache Software Foundation..  Does that seem correct?

 Actually I'm not sure whether used is correct, project have been using
 Mozilla's tinderbox back then.  I committed a change with developed
 rather than used in the sentence above.  Feel free to correct it.

Looks fine to me.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Help needed with ASF Branding Requirements

[sebb]

On 3 June 2011 07:58, Stefan Bodewig bode...@apache.org wrote:
 Hi all,

 there is an updated version of the branding requirements[1] and I just
 went through it.  There is one thing left from the checklist and some
 things have changed.

 What has changed is that the project name in the description has to be
 used as an adjective rather than a noun.  My problem with the example is
 that if I translate The Apache Xerces XML parsing library to German
 Apache Xerces remains a noun so I'm not really sure I actually
 understand the concept of adjectives in the English language 8-)

The noun in this case is library.
Apache Xerces is here being used as a qualifier.

 It seems that we need to combine Apache Gump with some extra noun(s).

 Right now we have Apache Gump is the oldest continuous integration tool
 of the Apache Sofware Foundation. and I propose to change it to The
 Apache Gump continuous integration tool was the first one used at the
 Apache Software Foundation..  Does that seem correct?

Seems fine to me.

 What hasn't changed is that the license link should go to the folder
 holding all versions of the AL rather than to the 2.0 version directly -
 I'll change that over the weekend.

 I think we cover all the rest of the requirements - but I'll double
 check - except for our logos that need TM symbols.  I'm still not
 capable of doing any artwork so please, who ever feels like using Gimp
 or Photoshop or Paint, you are more than welcome to TMify the bench
 logos (the one on our main site as well as the one on our reports).

 Stefan

 [1] http://www.apache.org/foundation/marks/pmcs

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r1090947 - /gump/metadata/profile/gump.xml

[sebb]

On 11 April 2011 07:24,  bode...@apache.org wrote:
 Author: bodewig
 Date: Mon Apr 11 06:24:37 2011
 New Revision: 1090947

 URL: http://svn.apache.org/viewvc?rev=1090947view=rev
 Log:
 revert rev 1090785 which changed way more than it intended

Sorry about that - not sure how that happened.

I would have thought that SVN should have complained that my working
copy was out of date.
It does normally when I have not refreshed sufficiently recently.


 Modified:
    gump/metadata/profile/gump.xml

 Modified: gump/metadata/profile/gump.xml
 URL: 
 http://svn.apache.org/viewvc/gump/metadata/profile/gump.xml?rev=1090947r1=1090946r2=1090947view=diff
 ==
 --- gump/metadata/profile/gump.xml (original)
 +++ gump/metadata/profile/gump.xml Mon Apr 11 06:24:37 2011
 @@ -111,11 +111,7 @@
   module href=project/anakia.xml/
   module href=project/jakarta-bcel.xml/
   module href=project/jakarta-bsf.xml/
 -!--
 -  Cannot solve runtime classpath issue, and now the scripting.dev.java.net 
 site is misbehaving
 -  There are no dependencies on BSF3, and it is stable, so disable the builds.
   module href=project/jakarta-bsf3.xml/
 ---
   module href=project/jakarta-cactus.xml/
   module href=project/httpcomponents.xml/
   module href=project/jakarta-jmeter.xml/
 @@ -318,6 +314,7 @@
   module href=project/cryptix.xml/

   module href=project/dougLea.xml/
 +  module href=project/google-guava.xml /
   module href=project/hamcrest.xml/
   module href=project/icu4j.xml/
   module href=project/javacc.xml/
 @@ -342,6 +339,7 @@
   module href=project/village.xml/
   module href=project/wsdl4j.xml/
   module href=project/packaged-jaxen.xml/
 +  module href=project/objenesis.xml/
   module href=project/org.mortbay.jetty.xml/

  !-- CodeHaus --
 @@ -383,11 +381,11 @@
   module href=project/packaged-xom.xml/
   module href=project/which4j.xml/
   module href=project/xom.xml/
 -  module href=project/hudson.xml/

  !-- OpenSAML --
   module href=project/opensaml.xml/
 -
 +  module href=project/opensaml-openws.xml/
 +  module href=project/opensaml-xmltooling.xml/

  !-- OpenSymphony --
   module href=project/opensymphony.xml/
 @@ -413,6 +411,7 @@
   project name=cryptix          package=cryptix32-20001002-r3.2.0/
   project name=commons-codec-11 package=apache-commons/
   project name=commons-jexl-1.x package=apache-commons/
 +  project name=commons-vfs-10   package=apache-commons/
   !--project name=dumbster         package=dumbster1.3/--
   project name=eclipse          package=eclipse/
   project name=ecs              package=apache-attic/
 @@ -481,7 +480,7 @@
   project name=packaged-xom     package=xom-1.1/
   project name=picocontainer    package=picocontainer-1.1/
   project name=propertyset      package=propertyset/
 -  project name=qdox             package=qdox-1.6.3/
 +  project name=qdox             package=qdox/
   project name=relaxng          package=relaxngDatatype-1.0/
   project name=retroweaver      package=retroweaver-2.0.7/
   project name=slide-webdavlib  package=apache-attic/
 @@ -507,6 +506,7 @@
   repository href=repository/dom4j-hg.xml/
   repository href=repository/eclipse.xml/
   repository href=repository/ggf-cddlm.xml/
 +  repository href=repository/google-guava.xml /
   repository href=repository/hamcrest.xml/
   repository href=repository/icu.xml/
   repository href=repository/ikayzo.xml/
 @@ -519,6 +519,7 @@
   repository href=repository/jython.xml/
   repository href=repository/mozilla.xml/
   repository href=repository/objectweb.xml/
 +  repository href=repository/objenesis.xml/
   repository href=repository/opensaml.xml/
   repository href=repository/pcre.xml/
   repository href=repository/slf4j.xml /




-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r1075910 - in /gump/metadata/project: directory-apacheds.xml directory-shared.xml

[sebb]

On 2 March 2011 05:04, Stefan Bodewig bode...@apache.org wrote:
 On 2011-03-01, Antoine Levy-Lambert wrote:

 Apache Directory Server has a lot of maven projects in it and they do
 a lot of refactoring.

 I know 8-)

 Would there not be something to do to automate the maintenance of gump
 descriptors for maven based projects ?

 Or even better, could gump be made able to read parent pom.xml files
 directly and reinterpret them as gump metadata ?

 The main problem is the mismatch of ids.  Gump's id space is flat and
 Maven has the tuple of groupId and artifactId.  In many cases we can use
 the artifactId but it is not always possible as things tend to clash
 from time to time (junit-addons is one such example).  I don't see an
 automated way to resolve this.

 Another problem is writing a POM parser for Gump that recursively chased
 down parent POMs and knew how to consider the dependencies of plugins
 (almost all mvn projects depend on Velocity via the site plugin).

 I do not have CPU cycles to develop that

 Me neither, sorry.

Some of the code is available from Maven itself - e.g.
help:effective-pom - but of course that output would then need to be
parsed.

Someone that knows Maven intermals well could probably produce a
plugin that returned the information Gump needs in a format that Gump
could easily use.

But I don't currently have that knowledge.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem locating XPathAPI, but only in test

[sebb]

On 18 January 2011 11:36, sebb seb...@gmail.com wrote:
 On 18 January 2011 11:20, Stefan Bodewig bode...@apache.org wrote:
 On 2011-01-13, sebb wrote:

 On 10 January 2011 20:26, sebb seb...@gmail.com wrote:
 On 10 January 2011 12:23, Stefan Bodewig bode...@apache.org wrote:

 It likely is part of xalan.jar which is present in -Xbootclaspath but
 not CLASSPATH.

 How does one add Xalan to the build classpath?  The JMeter project
 depends on Xalan, but it does not seem to get added to the classpath,
 only the bootclasspath.

 It should be going into the forked VM's bootclasspath via Ant's
 build.sysclasspath.  If this is not the case then something inside Ant
 has been broken.

 So Xalan is handled differently from other dependencies?

 Right now I don't have the time to follow this through.  I suspect newer
 OpenJDKs no longer use the system property sun.boot.class.path but
 rather something new without sun in its name to provide the
 bootclasspath to the running application.  If so Ant's
 Path.systemBootClasspath ends up empty and can't be propagated to the
 forked VM.  Ant would need to get fixed which in turn should fix the
 Gump build (likely Forrest's as well) since Gump uses Ant's trunk.

 And maybe BSF3 as well...

 I don't know when I'll have the cycles to confirm my suspicion, sorry.

 OK, no problem.

 I can try adding some debugging to the build file.

Ant is not passing -bootclasspath to the forked java task that runs the test.

Adding the Xalan jars to the test run using work parent=
references fixes the problem by adding the jars to the test classpath.

However, this is a bit messy, as the paths may perhaps change.

Just tried adding clonevm=true to the java task, but that causes
problems for non-Gump builds.

I'm beginning to think this may be a Gump bug: although Xalan is
listed as a normal dependency, it is not added to the classpath, only
to the bootclasspath.

 Stefan


 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem locating XPathAPI, but only in test

[sebb]

On 18 January 2011 11:20, Stefan Bodewig bode...@apache.org wrote:
 On 2011-01-13, sebb wrote:

 On 10 January 2011 20:26, sebb seb...@gmail.com wrote:
 On 10 January 2011 12:23, Stefan Bodewig bode...@apache.org wrote:

 It likely is part of xalan.jar which is present in -Xbootclaspath but
 not CLASSPATH.

 How does one add Xalan to the build classpath?  The JMeter project
 depends on Xalan, but it does not seem to get added to the classpath,
 only the bootclasspath.

 It should be going into the forked VM's bootclasspath via Ant's
 build.sysclasspath.  If this is not the case then something inside Ant
 has been broken.

So Xalan is handled differently from other dependencies?

 Right now I don't have the time to follow this through.  I suspect newer
 OpenJDKs no longer use the system property sun.boot.class.path but
 rather something new without sun in its name to provide the
 bootclasspath to the running application.  If so Ant's
 Path.systemBootClasspath ends up empty and can't be propagated to the
 forked VM.  Ant would need to get fixed which in turn should fix the
 Gump build (likely Forrest's as well) since Gump uses Ant's trunk.

And maybe BSF3 as well...

 I don't know when I'll have the cycles to confirm my suspicion, sorry.

OK, no problem.

I can try adding some debugging to the build file.

 Stefan


 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem locating XPathAPI, but only in test

[sebb]

On 10 January 2011 20:26, sebb seb...@gmail.com wrote:
 On 10 January 2011 12:23, Stefan Bodewig bode...@apache.org wrote:
 On 2011-01-09, sebb wrote:

 Strange problem trying to test JMeter:

 http://vmgump.apache.org/gump/public/jakarta-jmeter/jakarta-jmeter-test/gump_work/build_jakarta-jmeter_jakarta-jmeter-test.html

 The test cannot find the class org/apache/xpath/XPathAPI

 Yet the compile works, and the classpath is almost identical (the
 differences don't contain xpath jars).

 Your tests are in a forked VM, right?  It looks as if the forked VM
 wouldn't see the same CLASSPATH as Ant itself.

 What is even odder, I've scanned all the jars in the build classpath,
 and XPathAPI does not appear there either, yet the sources refer to it
 and build OK.

 It likely is part of xalan.jar which is present in -Xbootclaspath but
 not CLASSPATH.

 Thanks! Yes, that seems to be the case.

 Tests work outside Gump because in that case all the dependencies are
 present in the lib/ directory.

 I'm not sure why the tests use fork - it appears to have been that way for 
 ages.
 They seem to work OK with fork=no, so I'll try that with Gump.

Actually, they don't work OK - they don't fail, but they don't run any tests ...

It's going to be difficult to rework the tests to not use fork, so I
now need to ensure that the classpath has the appropriate
dependencies.

How does one add Xalan to the build classpath?
The JMeter project depends on Xalan, but it does not seem to get added
to the classpath, only the bootclasspath.

 Thanks again.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Gump on adam.a.o trouble with Forrest build

[sebb]

On 11 January 2011 08:36, Stefan Bodewig bode...@apache.org wrote:
 On 2011-01-11, David Crossley wrote:

 Is there some way to stop the two projects just on adam.a.o
 that were causing it to hang for one hour each:
 (forrest-test-basic and forrest-test).
 I think that i have asked that before, and answer is no.

 The only way would be if adam used a different profile than the rest of
 the machines.

Perhaps consider extending Gump to provide conditional execution of
modules/projects?

That way the build could be skipped e.g. based on host name or host OS
or availability of a particular compiler.

Just a thought - it might involve a too much work for the benefit.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem locating XPathAPI, but only in test

[sebb]

On 10 January 2011 12:23, Stefan Bodewig bode...@apache.org wrote:
 On 2011-01-09, sebb wrote:

 Strange problem trying to test JMeter:

 http://vmgump.apache.org/gump/public/jakarta-jmeter/jakarta-jmeter-test/gump_work/build_jakarta-jmeter_jakarta-jmeter-test.html

 The test cannot find the class org/apache/xpath/XPathAPI

 Yet the compile works, and the classpath is almost identical (the
 differences don't contain xpath jars).

 Your tests are in a forked VM, right?  It looks as if the forked VM
 wouldn't see the same CLASSPATH as Ant itself.

 What is even odder, I've scanned all the jars in the build classpath,
 and XPathAPI does not appear there either, yet the sources refer to it
 and build OK.

 It likely is part of xalan.jar which is present in -Xbootclaspath but
 not CLASSPATH.

Thanks! Yes, that seems to be the case.

Tests work outside Gump because in that case all the dependencies are
present in the lib/ directory.

I'm not sure why the tests use fork - it appears to have been that way for ages.
They seem to work OK with fork=no, so I'll try that with Gump.

Thanks again.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Problem locating XPathAPI, but only in test

[sebb]

Strange problem trying to test JMeter:

http://vmgump.apache.org/gump/public/jakarta-jmeter/jakarta-jmeter-test/gump_work/build_jakarta-jmeter_jakarta-jmeter-test.html

The test cannot find the class org/apache/xpath/XPathAPI

Yet the compile works, and the classpath is almost identical (the
differences don't contain xpath jars).

What is even odder, I've scanned all the jars in the build classpath,
and XPathAPI does not appear there either, yet the sources refer to it
and build OK.

Any suggestions?

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r1044741 - /gump/trunk/cron/gump.bat

[sebb]

On 11 December 2010 23:26,  billbar...@apache.org wrote:
 Author: billbarker
 Date: Sat Dec 11 23:26:04 2010
 New Revision: 1044741

 URL: http://svn.apache.org/viewvc?rev=1044741view=rev
 Log:
 fix line endings since only useful on windows

In which case, maybe CRLF would be better than native?

As it stands, if an archive is created on Unix, it won't have the
correct EOL for the bat file (unless the build process fixes this).


 Modified:
    gump/trunk/cron/gump.bat   (props changed)

 Propchange: gump/trunk/cron/gump.bat
 --
    svn:eol-style = native

 Propchange: gump/trunk/cron/gump.bat
 --
 --- svn:mime-type (original)
 +++ svn:mime-type Sat Dec 11 23:26:04 2010
 @@ -1 +1 @@
 -application/octet-stream
 +text/plain




-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: xml-apis fails

[sebb]

On 9 December 2010 05:33, Stefan Bodewig bode...@apache.org wrote:
 On 2010-12-09, Ludmila Shikhvarg wrote:

 Use windows 7 with cygwin environment to run gump,

 I don't think anybody has ever tried to run Gump on Windows and I'm very
 sure there are a few unixisms inside the code.  It's probably fair to
 assume it simply won't work and Gump requires a Unix-like system with
 Unix conventions for paths and filenames.  In particular java must use
 Unix like conventions.

Not sure that's true.

      Command Line

 c:/jdk1.6.0_21/bin/java
        
 -Xbootclasspath/p:/home/dtftest/gump/packages/jaxp-1_3/jaxp-api.jar:/home/dtftest/gump/packages/jaxp-1_3/dom.jar:/home/dtftest/gump/packages/jaxp-1_3/sax.jar:/home/dtftest/gump/packages/jaxp-1_3/xercesImpl.jar:/home/dtftest/gump/packages/jaxp-1_3/xalan.jar
        org.apache.tools.ant.Main 
 -Dgump.merge=/home/dtftest/gump/work/merge.xml

There should be a space or = after -Xbootclasspath - that might
explain the the problem?


 The bootclasspath is not a Windows path, this likely won't work at all.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

[jira] Created: (GUMP-161) Apache Gump Metadata does not show actual version used

[Sebb (JIRA)]

Apache Gump Metadata does not show actual version used
--

 Key: GUMP-161
 URL: https://issues.apache.org/jira/browse/GUMP-161
 Project: Gump
  Issue Type: Bug
Reporter: Sebb
Priority: Minor


The Apache Gump Metadata link points to SVN. As such, it may show a more recent 
version than was actually used.

It would be helpful to show the actual metadata file, either in the workspace, 
or by including the SVN revision of the file.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r1035144 - /gump/metadata/project/commons-proper.xml

[sebb]

On 15 November 2010 04:59,  bode...@apache.org wrote:
 Author: bodewig
 Date: Mon Nov 15 04:59:23 2010
 New Revision: 1035144

 URL: http://svn.apache.org/viewvc?rev=1035144view=rev
 Log:
 make it well-formed

Sorry about that - missed the embedded comment.


 Modified:
    gump/metadata/project/commons-proper.xml

 Modified: gump/metadata/project/commons-proper.xml
 URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/commons-proper.xml?rev=1035144r1=1035143r2=1035144view=diff
 ==
 --- gump/metadata/project/commons-proper.xml (original)
 +++ gump/metadata/project/commons-proper.xml Mon Nov 15 04:59:23 2010
 @@ -947,7 +947,6 @@
     option project=xml-xerces/
     option project=commons-logging/
     option project=commons-collections/
 -    !--option project=commons-compress/--
     option project=commons-httpclient-2.0-branch/
     option project=commons-net/
     option project=doxia-site-renderer/




-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r1001631 - /gump/metadata/project/checkstyle.xml

[sebb]

On 27 September 2010 10:07,  bode...@apache.org wrote:
 Author: bodewig
 Date: Mon Sep 27 09:07:30 2010
 New Revision: 1001631

 URL: http://svn.apache.org/viewvc?rev=1001631view=rev
 Log:
 I don't know why wildcards sometimes don't seem to work

 Modified:
    gump/metadata/project/checkstyle.xml

 Modified: gump/metadata/project/checkstyle.xml
 URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/checkstyle.xml?rev=1001631r1=1001630r2=1001631view=diff
 ==
 --- gump/metadata/project/checkstyle.xml (original)
 +++ gump/metadata/project/checkstyle.xml Mon Sep 27 09:07:30 2010
 @@ -37,7 +37,7 @@
     option project=commons-validator/
     option project=junit/

 -    jar name=target/checkstyle-*[0-9T].jar
 +    jar name=target/checkstyle-5.3-SNAPSHOT.jar

Perhaps they don't work because of the -SNAPSHOT suffix?

          id=checkstyle/

     license name=LICENSE/




-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r1001631 - /gump/metadata/project/checkstyle.xml

[sebb]

On 27 September 2010 11:48, Stefan Bodewig bode...@apache.org wrote:
 On 2010-09-27, sebb wrote:

 On 27 September 2010 10:07,  bode...@apache.org wrote:

 I don't know why wildcards sometimes don't seem to work

 -    jar name=target/checkstyle-*[0-9T].jar
 +    jar name=target/checkstyle-5.3-SNAPSHOT.jar

 Perhaps they don't work because of the -SNAPSHOT suffix?

 No, that works in several other projects.  And the wildcard should still
 match anyway (that's why there is a T in the group).


Sorry, I see now. I wondered what the T was doing!

 My best guess currently is - and confirming/fixing it is on my TODO
 list, somewhere - that under certain circumstances the wildcards get
 expanded before the jar has actually been built.

What happens if the wildcard matches more than one file?
Could that cause a problem for the code?

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r1001631 - /gump/metadata/project/checkstyle.xml

[sebb]

On 27 September 2010 11:56, Maarten Coene maarten_co...@yahoo.com wrote:
 If the pattern has to be a regular expression, it should be:
 jar name=target/checkstyle-.*[0-9T].jar /

I've just found that it's a shell glob pattern:

http://gump.apache.org/metadata/project.html#jar

 Maarten

 --- On Mon, 9/27/10, Stefan Bodewig bode...@apache.org wrote:

 From: Stefan Bodewig bode...@apache.org
 Subject: Re: svn commit: r1001631 - /gump/metadata/project/checkstyle.xml
 To: general@gump.apache.org
 Date: Monday, September 27, 2010, 12:48 PM
 On 2010-09-27, sebb wrote:

  On 27 September 2010 10:07,  bode...@apache.org
 wrote:

  I don't know why wildcards sometimes don't seem to
 work

  -    jar
 name=target/checkstyle-*[0-9T].jar
  +    jar
 name=target/checkstyle-5.3-SNAPSHOT.jar

  Perhaps they don't work because of the -SNAPSHOT
 suffix?

 No, that works in several other projects.  And the
 wildcard should still
 match anyway (that's why there is a T in the group).

 My best guess currently is - and confirming/fixing it is on
 my TODO
 list, somewhere - that under certain circumstances the
 wildcards get
 expanded before the jar has actually been built.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org






 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem with collections test dependency

[sebb]

On 14 September 2010 04:47, Stefan Bodewig bode...@apache.org wrote:
 On 2010-09-14, sebb wrote:

 On 13 September 2010 20:41, Stefan Bodewig bode...@apache.org wrote:

 There are (at least) two solutions:

 * make Digester explicitly depend on commons-collections (may not help
  SCXML).

 Already tried that - does not seem to help.

 What I meant was in Digester's POM, not inside the Gump descriptor.

I see.

Given that Digester does not depend directly on collections, it would
be a pain to have to administer collections version changes.

 * publish commons-beanutils' POM together with the jar to the mvn proxy
  (just a matter of adding a pom element to the Gump descriptor) so
  commons-collections ends up being a transitive dependency for digester
  and scxml.

 Now trying that.

 OK

Works!

Thanks.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Access to Surefire test output

[sebb]

If a Surefire test fails, it's usually necessary to be able to read
the file(s) in the surefire-reports directory to resolve the problem.

However, the Gump mails don't seem to give access to this information,
unless one adds a suitable report tag to the descriptor.
This is very tedious to have to do for every test.

Is there a better way to get access to the surefire output?

Indeed, perhaps there should be easy read access to all of the Gump
output directories?
Could that be done via suitable config of the HTTP server?

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r996958 - /gump/metadata/project/commons-proper.xml

[sebb]

On 14 September 2010 18:49, Stefan Bodewig bode...@apache.org wrote:
 On 2010-09-14, s...@apache.org wrote:

 -    pom name=jci/pom.xml/
 +    pom name=../pom.xml/

 Uhm, no.  I've reverted that part.

Sorry ...

 The commons-beanutils project has a home element that points at
 beanutils/dist - that's why the .. was needed - pom and jar are
 resolved relative to home.

 commons-jci doesn't have a home element so its home dir is the checked
 out trunks directory.

... thanks for the explanation.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem with collections test dependency

[sebb]

On 13 September 2010 05:11, Stefan Bodewig bode...@apache.org wrote:
 On 2010-09-13, sebb wrote:

 On 13 September 2010 03:36, Bill Barker billwbar...@verizon.net wrote:

 I thought you had a login account on vmgump.  But anyway:

 I did have on the previous incarnation.

 If I have one on the current Gump it's not working for me.

 Do you want one?

If possible, yes, it would be useful to have a login again.


 Is it possible that the test phase is picking up the wrong collections
 jar somehow?

 The project commons-collections4 isn't doing an 'install' target, so
 shouldn't be overwriting commons-collections.  However the
 commons-digester build log shows:

 Downloading:
 http://localhost:8192/maven2/commons-collections/commons-collections/2.0/commons-collections-2.0.jar

 Even if commons-collections4 builds before digester, mvn will not
 download it but commons-collections built from the 3.x branch because
 collections4 uses org.apache.commons as groupId.

 Is there a way to show the classpath used by Surefire?

 Don't know enough about M2 to answer this one.

 FWIU CLASSPATH is completely irrelevant for Surefire.  Surefire uses
 what you specify inside your POM, that's it.

Not sure I follow - does that mean that Gump does not override the
Maven definitions for Surefire?

 This also means you can add/remove whatever you want to/from the
 dependencies of any mvn project, it doesn't make any difference.  The
 only thing that matters is build order.

Commons-scxml-test [1] fails with the same classpath problem
[3],[4],[5], even though collections3 is on the classpath [2]

If the Gump descriptor does not affect Surefire, how can Gump be told
to use the exact same dependencies for both build and test?

[1] 
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html
[2] 
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/details.html
[3] 
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_file/org.apache.commons.scxml.io.IOTestSuite.txt.html
[4] 
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_file/org.apache.commons.scxml.model.ModelTestSuite.txt.html
[5] 
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_file/org.apache.commons.scxml.issues.IssuesTestSuite.txt.html


 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem with collections test dependency

[sebb]

On 13 September 2010 20:41, Stefan Bodewig bode...@apache.org wrote:
 On 2010-09-13, sebb wrote:

 On 13 September 2010 05:11, Stefan Bodewig bode...@apache.org wrote:

 FWIU CLASSPATH is completely irrelevant for Surefire.  Surefire uses
 what you specify inside your POM, that's it.

 Not sure I follow - does that mean that Gump does not override the
 Maven definitions for Surefire?

 Gump can't, mvn doesn't allow it to.

 Gump installs a proxy between mvn and the central repo (as well as a few
 well know other repositories) and when mvn asks for an artifact that has
 already been built by Gump (ignoring versions) the proxy will hand out
 Gump's jar - otherwise the one from central will be provided.

 So build order decides what may be available the POM decided what mvn
 asks for in the first place.  You can influence things by pushing a
 custom POM into the mvn proxy (I've done so for Xalan so that anybody
 who needs Xalan also requires serializer.jar) but this hasn't been done
 often so far.

 If a project asks for commons-collections with groupId
 commons-collections it will get the one built by Gump from the 3.x
 branch - if that has already been built - or the one from central.
 commons-collections4 should never be provided to a project unless mvn is
 asking for the groupId org.apache.commons.

 Commons-scxml-test [1] fails with the same classpath problem
 [3],[4],[5], even though collections3 is on the classpath [2]

 The root cause is a change in commons-beanutils.
 http://svn.apache.org/viewvc?view=revisionrevision=995833

 SCXML depends on Digester depends on Beanutils.  The latter now (in
 trunk) depends on commons-collections.  Digester uses the POM from
 commons-beanutils in central which only has an optional dependency on
 commons-collections and the jar built by Gump where it has become
 non-optional.

 There are (at least) two solutions:

 * make Digester explicitly depend on commons-collections (may not help
  SCXML).

Already tried that - does not seem to help.

 * publish commons-beanutils' POM together with the jar to the mvn proxy
  (just a matter of adding a pom element to the Gump descriptor) so
  commons-collections ends up being a transitive dependency for digester
  and scxml.

Now trying that.

 Stefan

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Problem with collections test dependency

[sebb]

Digester depends on collections, but fails at run-time because the class
org/apache/commons/collections/FastHashMap is not present.

However, the classpath includes commons-collections-3.3-SNAPSHOT.jar
which should include this class.
Is there a way to get access to the jar to check its contents?

Is it possible that the test phase is picking up the wrong collections
jar somehow?
Is there a way to show the classpath used by Surefire?

Note that collections4 does not contain FastHashMap.

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem with collections test dependency

[sebb]

On 13 September 2010 03:36, Bill Barker billwbar...@verizon.net wrote:


 --
 From: sebb seb...@gmail.com
 Sent: Sunday, September 12, 2010 5:00 AM
 To: general@gump.apache.org
 Subject: Problem with collections test dependency

 Digester depends on collections, but fails at run-time because the class
 org/apache/commons/collections/FastHashMap is not present.

 However, the classpath includes commons-collections-3.3-SNAPSHOT.jar
 which should include this class.
 Is there a way to get access to the jar to check its contents?


 I thought you had a login account on vmgump.  But anyway:

I did have on the previous incarnation.

If I have one on the current Gump it's not working for me.


 billbar...@vmgump:~/gump/public/workspace/commons-collections-3.x/target$
 jar tf commons-collections-3.3-SNAPSHOT.jar | grep Fast
 org/apache/commons/collections/FastArrayList$SubList$SubListIter.class
 org/apache/commons/collections/FastHashMap.class
 org/apache/commons/collections/FastHashMap$CollectionView$CollectionViewIterator.class
 org/apache/commons/collections/FastHashMap$EntrySet.class
 org/apache/commons/collections/FastTreeMap.class
 org/apache/commons/collections/FastTreeMap$Values.class
 org/apache/commons/collections/FastTreeMap$1.class
 org/apache/commons/collections/FastHashMap$Values.class
 org/apache/commons/collections/FastArrayList.class
 org/apache/commons/collections/FastArrayList$SubList.class
 org/apache/commons/collections/FastHashMap$CollectionView.class
 org/apache/commons/collections/FastHashMap$KeySet.class
 org/apache/commons/collections/FastTreeMap$EntrySet.class
 org/apache/commons/collections/FastHashMap$1.class
 org/apache/commons/collections/FastArrayList$ListIter.class
 org/apache/commons/collections/FastTreeMap$CollectionView$CollectionViewIterator.class
 org/apache/commons/collections/FastTreeMap$KeySet.class
 org/apache/commons/collections/FastTreeMap$CollectionView.class

Thanks!


 Is it possible that the test phase is picking up the wrong collections
 jar somehow?

 The project commons-collections4 isn't doing an 'install' target, so
 shouldn't be overwriting commons-collections.  However the commons-digester
 build log shows:

 Downloading:
 http://localhost:8192/maven2/commons-collections/commons-collections/2.0/commons-collections-2.0.jar
 Downloading:
 http://localhost:8192/maven2/org/codehaus/plexus/plexus-velocity/1.1.3/plexus-velocity-1.1.3.jar
 566K downloaded  (commons-collections-2.0.jar)

 Is there a way to show the classpath used by Surefire?


 Don't know enough about M2 to answer this one.

Now that the test phase is in a separate project, it seems that the
required test dependencies - including collections3 - are missing from
the classpath.

I'll add / move the dependencies and see if that fixes things.

Thanks for confirming that the jar has the correct contents.

 Note that collections4 does not contain FastHashMap.

 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org


 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Update bouncycastle version?

[sebb]

On 30/06/2010, Stefan Bodewig bode...@apache.org wrote:
 On 2010-06-29, sebb wrote:

   Would it be possible to install a more recent version?
   The current BC release is 1.45.


 Both vmgump and the Solaris zone now provide 145

Excellent, thanks!

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Update bouncycastle version?

[sebb]

JMeter is failing to build because the BC package is rather out of
date, and does not have all the required classes.

Would it be possible to install a more recent version?
The current BC release is 1.45.

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: sshd config change on vmgump

[sebb]

On 16/04/2010, Sander Temme san...@temme.net wrote:
 Folks,

  Following the recent havoc on ASF servers, new rules have been imposed on 
 sshd keys and the use of passwords.

  I have implemented the first part of this today by changing the sshd 
 configuration.  Right now, the only ones that have sshd access are myself and 
 Infra's Joe Schaefer and Mark Thomas.

  I am seeing the following accounts on the VM:

  leosimons
  bodewig
  brett
  billbarker
  dims
  mvdb
  sebb

  Who (still) needs sshd access?  I can migrate keys accordingly.

I do still occaisionally find shell access to Gump useful for
debugging failed runs, but I cannot really claim that I *need* access.

If there was an easy way to get read-only access to the Gump
workspaces (rather than just the reports) I would not need a login.

  Next up, implementation of OPIE which has to happen by May 1 Or Else.

  Thanks,

  S.


  --
  san...@temme.net  http://www.temme.net/sander/
  PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF


  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r934914 - in /gump/metadata/project: db-ojb.xml jakarta-slide.xml

[sebb]

On 16/04/2010, bode...@apache.org bode...@apache.org wrote:
 Author: bodewig
  Date: Fri Apr 16 14:27:48 2010
  New Revision: 934914

  URL: http://svn.apache.org/viewvc?rev=934914view=rev
  Log:
  remove references to commons-transaction

  Modified:
 gump/metadata/project/db-ojb.xml
 gump/metadata/project/jakarta-slide.xml

Oops, sorry, forgot there might be dependencies...

  Modified: gump/metadata/project/db-ojb.xml
  URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/db-ojb.xml?rev=934914r1=934913r2=934914view=diff
  
 ==
  --- gump/metadata/project/db-ojb.xml (original)
  +++ gump/metadata/project/db-ojb.xml Fri Apr 16 14:27:48 2010
  @@ -51,7 +51,6 @@
  depend project=commons-lang-2.x/
  depend project=commons-logging/
  depend project=commons-pool/
  -depend project=commons-transaction/
  depend project=db-ddlutils/
  depend project=commons-betwixt/
  depend project=commons-graph/
  @@ -117,7 +116,6 @@
  depend project=commons-lang-2.x/
  depend project=commons-logging/
  depend project=commons-pool/
  -depend project=commons-transaction/
  depend project=db-ddlutils/
  depend project=commons-betwixt/
  depend project=commons-graph/

  Modified: gump/metadata/project/jakarta-slide.xml
  URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/jakarta-slide.xml?rev=934914r1=934913r2=934914view=diff
  
 ==
  --- gump/metadata/project/jakarta-slide.xml (original)
  +++ gump/metadata/project/jakarta-slide.xml Fri Apr 16 14:27:48 2010
  @@ -41,7 +41,6 @@
  depend project=antlr/
  depend project=commons-httpclient-2.0-branch/
  depend project=commons-httpclient-contrib/
  -depend project=commons-transaction/
  depend project=commons-xmlio/
  depend project=dist-ant/
  depend project=j2ee-connector/




-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Access to Maven settings for BSF Gump build

[sebb]

On 01/04/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 Hi Brett,

  Brett Randall wrote:


  snip/
  
   I'd bet that the retroweaver will produce everytime the same thing.
   However, md5sums (ans sha1sum) is generated by the deploy plugin
   automatically and will always validate the deployed jar itself.
  
   - Jörg
  
   snip/
  
   For the md5sum I was referring to an md5sum run against .class files
   extracted from the retro-weaved JAR, varying from build to build.  On
   the bsf-engines module from the 3.x branch, this can be observed by
   running the following command twice:
  
   bsf-engines$ mvn clean install  unzip -p
   target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class |
   md5sum
   snip/
   c6817d078ad972bcf1716e05e4c7f52f  -
   bsf-engines$ mvn clean install  unzip -p
   target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class |
   md5sum
   snip/
   49fb13a50a5c8bbf88823f31ca882680  -
  
   Not sure what to make of that - is it retroweaver?  Maybe retroweaver
   places some datetime related info into the instrumented class-file.


If you compare the classfiles, the last few bytes of each file are
slightly different.
Dunno if this is a datestamp or not.

However, the dates of the class files are also different; this is
probably caused by the repackaging process in the Ant script.

 It have to be retroweaver then..

And Ant.


   It doesn't matter, just pointing out that this tripped me when I was
   trying to fix the build and test that I was producing the exact same
   artifact with the new build.  It turns out that the artifact will be
   different from build to build without changes, unless I am missing
   something.


 That's simply unfortunate. :-/


  - Jörg



  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Access to Maven settings for BSF Gump build

[sebb]

On 31/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 Hi Brett,

  Brett Randall wrote:


  On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible joerg.schai...@gmx.de
   wrote:
   sebb wrote:
  
   On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:


 [snip]


   The question is, why do you install with Ant at all? Simply drop that
   goal,
   use the build-helper plugin to attach the artifact and you're done
   *and* it will be automatically deployed then also.
  
  
   Sounds great - I did not know about that Maven feature.
  
   I'll give it a try.
  
   Hehe, that explains it ;-)
  
   With the build helper you can turn any file into a separate artifact -
   useful e.g. for XML schemas and the like.
  
   At least this will ensure that the bsf-engines will be deployed next time
   also and the process is transparent for Gump.
  
   - Jörg
  
  
   -
   To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
   For additional commands, e-mail: general-h...@gump.apache.org
  
  
  
   This is a good outcome and the build is now green on Gump.  I hadn't
   thought of using build-helper but that's a decent option.
  
   I actually had this working on my local with a different approach
   initially suggested by Sebb - changing the primary artifact to jar
   packaging (from pom), then changing the retroweaver execution/output
   so that it fed the merged/weaved classes back into the Maven paths, so
   the normal execution of jar:jar picked them back up and the resulting
   primary artifact was packaged (and later deployed) as normal by Maven.
Using build-helper will result in the jar continuing to be built by
   Retroweaver rather than being packaged by Maven.  This probably
   doesn't matter - the JAR just won't look like a Maven JAR, contain the
   metadata etc.


 Actually there is not really a Maven JAR. It simply the default
  configuration for Maven's archiver to add the metadata, we turned that off
  everywhere in the office.

Huh? What does the last phrase mean?

 So the result of the retroweaver is a perfect artifact.

There is a META-INF directory, but it does not contain any Maven properties etc.


   The reason I hadn't published this is that I thought I had made a
   change that was effecting the binary output - I now suspect that each
   time Retroweaver runs it produces different binary output (class
   files) as checked by md5sum, so my solution was probably OK.


 I'd bet that the retroweaver will produce everytime the same thing. However,
  md5sums (ans sha1sum) is generated by the deploy plugin automatically and
  will always validate the deployed jar itself.


  - Jörg


  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Access to Maven settings for BSF Gump build

[sebb]

On 31/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 sebb wrote:

   On 31/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:


 [snip]


   Actually there is not really a Maven JAR. It simply the default
configuration for Maven's archiver to add the metadata, we turned that
off everywhere in the office.
  
   Huh? What does the last phrase mean?


 Each plugin that creates a Java archive (jar, ear, war, ...) contains an
  archive element in its configuration:

  http://maven.apache.org/shared/maven-archiver/#class_archive

  Simply set addMavenDescriptor to false


   So the result of the retroweaver is a perfect artifact.
  
   There is a META-INF directory, but it does not contain any Maven
   properties etc.


 Exactly what happens when you turn it off ;-)

I think we are talking about different things here.

The jar is currently created by the Ant build script, so does not have
the Maven descriptor.

AFAICT, changing the addMavenDescriptor setting won't have any effect.

So:
- do we need the Maven descriptor in the jar?
- if so, how do we add it? Can the build-helper add it?



  [snip]


  - Jörg


  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Access to Maven settings for BSF Gump build

[sebb]

On 29/03/2010, Brett Randall brand...@endeca.com wrote:
 In relation to the long-outstanding build failure of BSF: 
 http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html

  I'd like to check the contents of the file 
 /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml .  Is that file 
 publicly available, and/or how can I review its contents?  I'm wondering if 
 the Gump local repository location for project builds changed in a way 
 incompatible with the BSF/Gump build some time ago.

$ ls -l /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml
-rw-r--r-- 1 gump gump 1127 2010-03-30 16:08
/srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml

=== cut here 
?xml version=1.0?
!--
# DO NOT EDIT  DO NOT EDIT  DO NOT EDIT  DO NOT EDIT  DO NOT EDIT  DO
NOT EDIT  DO NOT EDIT
#
# File Automatically Generated by Gump, see http://gump.apache.org/
#
# Generated For : jakarta-bsf3
# Generated At  : 2010-03-30 08:08:02
#
#
# DO NOT EDIT  DO NOT EDIT  DO NOT EDIT  DO NOT EDIT  DO NOT EDIT  DO
NOT EDIT  DO NOT EDIT
--
settings
  
localRepository/srv/gump/public/workspace/mvnlocalrepo/localRepositorymirrors
mirror
  idgump-central/id
  nameGump proxying central/name
  urlhttp://localhost:8192/maven2/url
  mirrorOfcentral/mirrorOf
/mirror
mirror
  idgump-apache.snapshots/id
  nameGump proxying apache.snapshots/name
  urlhttp://localhost:8192/repo/m2-snapshot-repository/url
  mirrorOfapache.snapshots/mirrorOf
/mirror
mirror
  idgump-maven2-repository.dev.java.net/id
  nameGump proxying maven2-repository.dev.java.net/name
  urlhttp://localhost:8192/maven/2/url
  mirrorOfmaven2-repository.dev.java.net/mirrorOf
/mirror/mirrors/settings
 cut here ===

  Thanks

 Brett


-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Access to Maven settings for BSF Gump build

[sebb]

On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 sebb wrote:

   On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
   Hi Brett,
  
  
Brett Randall wrote:
  
 In relation to the long-outstanding build failure of BSF:
 http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html

 I'd like to check the contents of the file
 /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml .  Is
 that
 file publicly available, and/or how can I review its contents?  I'm
 wondering if the Gump local repository location for project builds
 changed in a way incompatible with the BSF/Gump build some time ago.
  
  
   bsf-engines is missing, because it is not deployed.
  
   But it *is* installed as part of the build.xml that downloads the
   engines and runs retroweaver on them - have a look earlier in the
   build output:
  
   http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
  bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
   snip
  
[exec] [INFO] [install:install-file {execution: default-cli}]
[exec] [INFO] Installing
   /srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
  engines-3.0-SNAPSHOT.jar
   to
   /home/gump/.m2/repository/org/apache/bsf/bsf-engines/3.0-SNAPSHOT/bsf-
  engines-3.0-SNAPSHOT.jar


 Yes, but it is not part of the reactor, because it is done by hand. Maven
  does not know that it is produced. Don't know if this has an effect on Gump,
  but it's quite suspicious that Gump fails to find this artifact. However,
  since Gump tries to build the examples, it will fail later anyway, because
  some of the dependend stuiff is no longer available.


Note that it builds happily on Hudson.

I think the problem is that Gump intercepts repository requests.

  
   Therefore it is also missing in the official 3.0 release ...
  
   No, that's because the Maven artifacts were not included in the release
   vote.


 OK, this is the wrong list for further comments on this. I have to bite my
  tongue.


  - Jörg


  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Access to Maven settings for BSF Gump build

[sebb]

On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 sebb wrote:

   On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
   sebb wrote:
  
 On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 Hi Brett,


  Brett Randall wrote:

   In relation to the long-outstanding build failure of BSF:
   http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
  bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
  
   I'd like to check the contents of the file
   /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml .
   Is that
   file publicly available, and/or how can I review its contents?
   I'm wondering if the Gump local repository location for project
   builds changed in a way incompatible with the BSF/Gump build some
   time ago.


 bsf-engines is missing, because it is not deployed.

 But it *is* installed as part of the build.xml that downloads the
 engines and runs retroweaver on them - have a look earlier in the
 build output:

 http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
 snip

  [exec] [INFO] [install:install-file {execution: default-cli}]
  [exec] [INFO] Installing
 /srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar
 to
 /home/gump/.m2/repository/org/apache/bsf/bsf-engines/3.0-SNAPSHOT/bsf-
engines-3.0-SNAPSHOT.jar
  
  
   Yes, but it is not part of the reactor, because it is done by hand.
   Maven
does not know that it is produced. Don't know if this has an effect on
Gump, but it's quite suspicious that Gump fails to find this artifact.
However, since Gump tries to build the examples, it will fail later
anyway, because some of the dependend stuiff is no longer available.
  
  
   Note that it builds happily on Hudson.
  
   I think the problem is that Gump intercepts repository requests.


 No, it is installed to the wrong place - probably because it is done by
  hand:


  Installing /srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
  engines-3.0-SNAPSHOT.jar to /home/gump/.m2/repository/org/apache/bsf/bsf-
  engines/3.0-SNAPSHOT/bsf-engines-3.0-SNAPSHOT.jar


 vs.

  Installing /srv/gump/public/workspace/jakarta-bsf3/bsf-api/target/bsf-
  api-3.0-SNAPSHOT.jar to
  /srv/gump/public/workspace/mvnlocalrepo/org/apache/bsf/bsf-api/3.0-
  SNAPSHOT/bsf-api-3.0-SNAPSHOT.jar

  Look at the target path ...


The command-line parameters are:

install:install-file -DgroupId=org.apache.bsf -DartifactId=bsf-engines
-Dversion=${bsf.version} -Dpackaging=jar -DgeneratePom=true
-Dfile=${basedir}/target/bsf-engines-${bsf.version}.jar

which are perfectly OK for non-Gump usage.

The command-line maven is not picking up the Gump override for the local repo.
So somehow one needs to tell the nested Maven invocation:

--settings  
/srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml

However, this *only* needs to be done for Gump runs, as the file won't
exist otherwise.

I'll have a look at that.

There's no documentation on M2 command-line options that I could find
- do you happen to know if the --settings value is saved in a maven
property?

  - Jörg


  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Access to Maven settings for BSF Gump build

[sebb]

On 30/03/2010, sebb seb...@gmail.com wrote:
 On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
   sebb wrote:
  
 On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 sebb wrote:

   On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
   Hi Brett,
  
  
Brett Randall wrote:
  
 In relation to the long-outstanding build failure of BSF:
 http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html

 I'd like to check the contents of the file
 /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml .
 Is that
 file publicly available, and/or how can I review its contents?
 I'm wondering if the Gump local repository location for project
 builds changed in a way incompatible with the BSF/Gump build 
 some
 time ago.
  
  
   bsf-engines is missing, because it is not deployed.
  
   But it *is* installed as part of the build.xml that downloads the
   engines and runs retroweaver on them - have a look earlier in the
   build output:
  
   http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
  bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
   snip
  
[exec] [INFO] [install:install-file {execution: default-cli}]
[exec] [INFO] Installing
   /srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
  engines-3.0-SNAPSHOT.jar
   to
   
 /home/gump/.m2/repository/org/apache/bsf/bsf-engines/3.0-SNAPSHOT/bsf-
  engines-3.0-SNAPSHOT.jar


 Yes, but it is not part of the reactor, because it is done by hand.
 Maven
  does not know that it is produced. Don't know if this has an effect on
  Gump, but it's quite suspicious that Gump fails to find this artifact.
  However, since Gump tries to build the examples, it will fail later
  anyway, because some of the dependend stuiff is no longer available.


 Note that it builds happily on Hudson.

 I think the problem is that Gump intercepts repository requests.
  
  
   No, it is installed to the wrong place - probably because it is done by
hand:
  
  
Installing /srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar to /home/gump/.m2/repository/org/apache/bsf/bsf-
engines/3.0-SNAPSHOT/bsf-engines-3.0-SNAPSHOT.jar
  
  
   vs.
  
Installing /srv/gump/public/workspace/jakarta-bsf3/bsf-api/target/bsf-
api-3.0-SNAPSHOT.jar to
/srv/gump/public/workspace/mvnlocalrepo/org/apache/bsf/bsf-api/3.0-
SNAPSHOT/bsf-api-3.0-SNAPSHOT.jar
  
Look at the target path ...
  


 The command-line parameters are:

  install:install-file -DgroupId=org.apache.bsf -DartifactId=bsf-engines
  -Dversion=${bsf.version} -Dpackaging=jar -DgeneratePom=true
  -Dfile=${basedir}/target/bsf-engines-${bsf.version}.jar

  which are perfectly OK for non-Gump usage.

  The command-line maven is not picking up the Gump override for the local 
 repo.
  So somehow one needs to tell the nested Maven invocation:

  --settings

 /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml


 However, this *only* needs to be done for Gump runs, as the file won't
  exist otherwise.

  I'll have a look at that.

  There's no documentation on M2 command-line options that I could find
  - do you happen to know if the --settings value is saved in a maven
  property?

Should have looked at the existing build.xml more thoroughly - the
local repo path is already passed in as it is used for picking up
retroweaver classes.

So I've added it to the maven argument list.

Works OK for me locally; hopefully it will keep Gump happy too.


- Jörg
  
  
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
  
  


-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Access to Maven settings for BSF Gump build

[sebb]

On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 sebb wrote:

   On 30/03/2010, sebb seb...@gmail.com wrote:
   On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 sebb wrote:

   On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
   sebb wrote:
  
 On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
 Hi Brett,


  Brett Randall wrote:

   In relation to the long-outstanding build failure of BSF:
   http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
  bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
  
   I'd like to check the contents of the file
   /srv/gump/public/workspace/jakarta-
  bsf3/gump_mvn_settings.xml
   . Is that
   file publicly available, and/or how can I review its
   contents? I'm wondering if the Gump local repository
   location for project builds changed in a way incompatible
   with the BSF/Gump build some time ago.


 bsf-engines is missing, because it is not deployed.

 But it *is* installed as part of the build.xml that downloads
 the engines and runs retroweaver on them - have a look earlier
 in the build output:

 http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
 snip

  [exec] [INFO] [install:install-file {execution:
  [default-cli}] exec] [INFO] Installing
 /srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar
 to
 /home/gump/.m2/repository/org/apache/bsf/bsf-engines/3.0-
  SNAPSHOT/bsf-
engines-3.0-SNAPSHOT.jar
  
  
   Yes, but it is not part of the reactor, because it is done by
   hand. Maven
does not know that it is produced. Don't know if this has an
effect on Gump, but it's quite suspicious that Gump fails to find
this artifact. However, since Gump tries to build the examples,
it will fail later anyway, because some of the dependend stuiff
is no longer available.
  
  
   Note that it builds happily on Hudson.
  
   I think the problem is that Gump intercepts repository requests.


 No, it is installed to the wrong place - probably because it is done
 by
  hand:


  Installing
  /srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
  engines-3.0-SNAPSHOT.jar to
  /home/gump/.m2/repository/org/apache/bsf/bsf-
  engines/3.0-SNAPSHOT/bsf-engines-3.0-SNAPSHOT.jar


 vs.

  Installing
  /srv/gump/public/workspace/jakarta-bsf3/bsf-api/target/bsf-
  api-3.0-SNAPSHOT.jar to
  /srv/gump/public/workspace/mvnlocalrepo/org/apache/bsf/bsf-api/3.0-
  SNAPSHOT/bsf-api-3.0-SNAPSHOT.jar

  Look at the target path ...

  
  
   The command-line parameters are:
  
install:install-file -DgroupId=org.apache.bsf -DartifactId=bsf-engines
-Dversion=${bsf.version} -Dpackaging=jar -DgeneratePom=true
-Dfile=${basedir}/target/bsf-engines-${bsf.version}.jar
  
which are perfectly OK for non-Gump usage.
  
The command-line maven is not picking up the Gump override for the local
repo. So somehow one needs to tell the nested Maven invocation:
  
--settings
  
   /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml
  
  
   However, this *only* needs to be done for Gump runs, as the file won't
exist otherwise.
  
I'll have a look at that.
  
There's no documentation on M2 command-line options that I could find
- do you happen to know if the --settings value is saved in a maven
property?
  
   Should have looked at the existing build.xml more thoroughly - the
   local repo path is already passed in as it is used for picking up
   retroweaver classes.
  
   So I've added it to the maven argument list.
  
   Works OK for me locally; hopefully it will keep Gump happy too.


 The question is, why do you install with Ant at all? Simply drop that goal,
  use the build-helper plugin to attach the artifact and you're done *and* it
  will be automatically deployed then also.


Sounds great - I did not know about that Maven feature.

I'll give it a try.

  - Jörg


  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r923057 - /gump/metadata/project/commons-proper.xml

[sebb]

On 15/03/2010, bode...@apache.org bode...@apache.org wrote:
 Author: bodewig
  Date: Mon Mar 15 05:23:18 2010
  New Revision: 923057

  URL: http://svn.apache.org/viewvc?rev=923057view=rev
  Log:
  canonical property to skip tests in mvn

  Modified:
 gump/metadata/project/commons-proper.xml

  Modified: gump/metadata/project/commons-proper.xml
  URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/commons-proper.xml?rev=923057r1=923056r2=923057view=diff
  
 ==
  --- gump/metadata/project/commons-proper.xml (original)
  +++ gump/metadata/project/commons-proper.xml Mon Mar 15 05:23:18 2010
  @@ -449,7 +449,7 @@
  descriptionCommons I/O Utility Package/description

  mvn basedir=io goal=package
  -  property name=skipTests value=true/
  +  property name=maven.test.skip.exec value=true/

maven.test.skip.exec is deprecated:

http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#skipExec

which is why I used skipTests.

  /mvn

  option project=commons-lang-2.x /




-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r923057 - /gump/metadata/project/commons-proper.xml

[sebb]

On 15/03/2010, Stefan Bodewig bode...@apache.org wrote:
 On 2010-03-15, sebb seb...@gmail.com wrote:

   On 15/03/2010, bode...@apache.org bode...@apache.org wrote:


   URL: http://svn.apache.org/viewvc?rev=923057view=rev
Log:
canonical property to skip tests in mvn


   -  property name=skipTests value=true/
+ property name=maven.test.skip.exec value=true/

   maven.test.skip.exec is deprecated:

   
 http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#skipExec

   which is why I used skipTests.


 I didn't know that and wanted things to be consistent - we use the now
  deprecated version all over the place.

  What is plugin version determined by?  The installed mvn version (2.2 by
  now) or the project's POM?

The project POM determines the version, assuming that the POM defines
the version.

  skipTests would require Surefire 2.4 to work
  and I don't know whether this is actually used by all projects.

Good point, but Commons-parent 13 uses 2.5

Note that skipExec itself requires 2.3, so could cause problems if a
project uses an earlier version of surefire.

Only skip is valid for all versions of Surefire, but that is not ideal.

  Stefan

  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: How to depend on legacy projects?

[sebb]

On 02/10/2009, Leo Simons m...@leosimons.com wrote:
 Hey sebb,


  On Sat, Sep 19, 2009 at 10:50 AM, sebb seb...@gmail.com wrote:
   JMeter currently depends on some legacy Excalibur modules:
  
   excalibur-datasource-1.1.1.jar
   excalibur-i18n-1.1.jar
   excalibur-instrument-1.0.jar
   excalibur-logger-1.1.jar
   excalibur-pool-1.2.jar


 Are you sure it really needs those specific versions? Modulo various
  small build system / packaging differences, the excalibur codebase has
  not changed significantly in many many years; I would kind-of expect
  JMeter to work with current excalibur trunk...

Quite possibly - Excalibur is only used for JDBC pooling.

  ciao,


  - Leo


  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: How to depend on legacy projects?

[sebb]

On 02/10/2009, sebb seb...@gmail.com wrote:
 On 02/10/2009, Leo Simons m...@leosimons.com wrote:
   Hey sebb,
  
  
On Sat, Sep 19, 2009 at 10:50 AM, sebb seb...@gmail.com wrote:
 JMeter currently depends on some legacy Excalibur modules:

 excalibur-datasource-1.1.1.jar
 excalibur-i18n-1.1.jar
 excalibur-instrument-1.0.jar
 excalibur-logger-1.1.jar
 excalibur-pool-1.2.jar
  
  
   Are you sure it really needs those specific versions? Modulo various
small build system / packaging differences, the excalibur codebase has
not changed significantly in many many years; I would kind-of expect
JMeter to work with current excalibur trunk...


 Quite possibly - Excalibur is only used for JDBC pooling.


Actually, there seems to be a problem depending on the latest versions
of Excalibur:


   [javac] 
/srv/gump/public/workspace/jakarta-jmeter/src/protocol/jdbc/org/apache/jmeter/protocol/jdbc/config/DataSourceElement.java:221:
cannot find symbol
   [javac] symbol  : method
enableLogging(org.apache.avalon.framework.logger.LogKitLogger)
   [javac] location: class
org.apache.avalon.excalibur.datasource.ResourceLimitingJdbcDataSource
   [javac] source.enableLogging(new LogKitLogger(log));
   [javac]   ^

See:

http://vmgump.apache.org/gump/public/jakarta-jmeter/jakarta-jmeter-svn/index.html

ciao,
  
  
- Leo
  
  
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
  
  


-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: How to depend on legacy projects?

[sebb]

On 21/09/2009, Stefan Bodewig bode...@apache.org wrote:
 On 2009-09-21, sebb seb...@gmail.com wrote:

   On 21/09/2009, Stefan Bodewig bode...@apache.org wrote:
   On 2009-09-19, sebb seb...@gmail.com wrote:

   JMeter currently depends on some legacy Excalibur modules:

   excalibur-datasource-1.1.1.jar
   excalibur-i18n-1.1.jar
   excalibur-instrument-1.0.jar
   excalibur-logger-1.1.jar
   excalibur-pool-1.2.jar


   We used to provide some of them as packaged projects until last Friday
when I removed all packages that weren't used by Ant or Maven 1 built
projects.  It shouldn't be too difficult to add them back, but the
effect would be the same as using work so I'd say stick with work.


   Surely work requires that the package be stored within SVN?


 Absolutely.  If your goal is to get rid off the jars in svn, then we
  will have to provide those as packaged projects.

Yes, I am removing the files from SVN.
The Ant build script now has a download target to fetch the files.

  Do you require all four of them?  The old excalibur-legacy project had
  i18n-1.1 and instrument-1.0, the others should still be available as
  Gump-built projects.

Just found that it don't require i18n, but JMeter does need the others.
It uses Excalibur pooling, so needs:

excalibur-datasource-1.1.1.jar
excalibur-instrument-1.0.jar
excalibur-pool-1.2.jar
excalibur-logger-1.1.jar (I think)

It also uses Avalon logging, so needs:
excalibur-logger-1.1.jar

I could perhaps replace Excalibur pooling with Commons Pool, but I've
not looked at that recently.


  Stefan

  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

How to depend on legacy projects?

[sebb]

JMeter currently depends on some legacy Excalibur modules:

excalibur-datasource-1.1.1.jar
excalibur-i18n-1.1.jar
excalibur-instrument-1.0.jar
excalibur-logger-1.1.jar
excalibur-pool-1.2.jar

These are currently referenced using work nested=lib/xxx.

All of these are also available in Maven repos, but JMeter does not
use Maven to build - is it possible to tell Gump to depend on the
copies in the repo?

JMeter also depends on jCharts 0.75 and htmlparser, which are not in
Maven as far as I can tell - how can one make these available to Gump?

-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: Problem running Apache Gump [vmgump-public]

[sebb]

On 14/09/2009, Stefan Bodewig bode...@apache.org wrote:
 On 2009-09-09, Stefan Bodewig bode...@apache.org wrote:

   I'm currently working going through the code in order to see where a
   retry on error logic could best be introduced.


 Looks as if it worked.

Well done  thanks!


  Stefan

  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: svn commit: r812413 - /gump/metadata/project/commons-proper.xml

[sebb]

On 08/09/2009, Stefan Bodewig bode...@apache.org wrote:
 On 2009-09-08, sebb seb...@gmail.com wrote:

   On 08/09/2009, Stefan Bodewig bode...@apache.org wrote:
   On 2009-09-08, s...@apache.org wrote:

   No longer using Ant build now that Jexl 2.0 is the trunk version
   Initial stab at M2 build

  mvn basedir=jexl/
  !-- Does it need a jar tag? --

If anybody depends on it and is supposed to use the generated jar, yes.

   It's used by Jelly.

   But what should it be?


 I don't think I understand the question.  The jar element should point
  to the jar created by the build process.  Given that we don't have any
  influence on the jar name in mvn builds, you must use the (-SNAPSHOT)
  version of the POM - and update the jar element whenever the POM is
  changed.


OK, thanks, that's what I meant. I'll update it shortly.

  Stefan

  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: SCM code changes status

[sebb]

On 16/02/2009, Stefan Bodewig bode...@apache.org wrote:
 Hi all,

  apart from some string constants that I want to extract (need to look
  up Python's idiom for constants) I'm now ready to move ahead - see the
  differences between svn revisions 741390 and 744799.

  I'll watch the next helios build and then try to merge trunk to live
  if it looks OK (I removed the directory sync feature by accident, so I
  better take a closer look).

  My tests for svn, CVS and git all work fine locally, I can't test
  Perforce.  If anybody uses Gump with p4 (I doubt so), please give
  trunk a try and talk about your results.

  Getting GIT installed is more complicated than I thought since I don't
  manage to compile it fom sources (not on helios, not on vmgump and not
  on any of my own machines running Intrepid, Hardy or OpenSUSE), so
  I'll try a few things with binaries.

  My changes to the SCM update code should enable new features more
  easily.

  In particular I want to make the updaters check whether an existing
  working copy is in fact a working copy for the configured URL - and
  blow it away if it isn't.  This way if anybody changes the repository
  for a module we wouldn't need to remove the old working copy manually
  anymore.  I'll probably give this a try before adding support for
  darcs, hg and bzr.

  The idea is to look into working-copy/CVS/Root and Repository,
  working-copy/.svn/entries and working-copy/.git/config respectively -

In the case of SVN, perhaps it would be safer to look at the output of
svn info rather than relying on the format of the SVN file?
Similarly for other SCMs.

  if anybody knows how to do the same for P4, I'll intergrate that as
  well.

  Stefan

  -
  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
  For additional commands, e-mail: general-h...@gump.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: [Gump Wiki] Update of www.buyyourall.com by buyyourall

[sebb]

On 22/12/2008, Sander Temme scte...@apache.org wrote:

  On Dec 22, 2008, at 7:53 AM, Apache Wiki wrote:


  The following page has been changed by buyyourall:
 

  Deleted, and (hopefully) banned.  Of course all of this will be in the
 mail-archives...


(S)he also spammed general and commons.

I've added the offending hostname to the Apache section of
general/BadContent so hopefully no more such spams will be possible.

  S.

  --
  Sander Temme
  scte...@apache.org
  PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF






-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org

Re: metadata

[sebb]

On 27/09/2008, David Crossley [EMAIL PROTECTED] wrote:
 sebb wrote:
  
   You probably only need the project directory:
  
   https://svn.apache.org/repos/asf/gump/metadata/project/


 The top-level contains the validate tool.

First I've heard of it ... but it's no use to me as I mostly use Windows ...

  Don't discourage them ;-)

  Total size = 6.4Mb
  project dir size = 4.8Mb

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: metadata

[sebb]

Works OK for me.

You probably only need the project directory:

https://svn.apache.org/repos/asf/gump/metadata/project/

On 26/09/2008, Matt Benson [EMAIL PROTECTED] wrote:
 What is the correct method for updating Gump metadata?
   I find myself unable to check out
  https://svn.apache.org/repos/asf/gump/metadata (URL
  ... doesn't exist).

  Thanks,
  Matt




  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: notification mails for ivy-tests

[sebb]

On 16/07/2008, Stefan Bodewig [EMAIL PROTECTED] wrote:
 On Tue, 15 Jul 2008, Stefan Bodewig [EMAIL PROTECTED] wrote:

   And I recall that Gump nags re-appeared on the commons lists after I
   changed the sender address (to mine).


 Same happened for ivy-tests now as well.  I changed the sender from
  [EMAIL PROTECTED] to [EMAIL PROTECTED] and the nags started to re-appear.

I think I've found the problem:

It looks like there are 3 Gump runs per day, starting at  0, 8, 16 hours (PDT).

Only the one starting at 0 hours is currently flagged as official,
so AIUI only that one will generate nags.

Also, if any of the runs last longer than 8 hours, then the next run
may not take place. Thus it is possible that the official runs don't
occur every day - and may indeed fail to run for several days in a
row. Indeed, in July so far only the following runs have the official
flag in the log files:

gump_log_02072008_04
gump_log_04072008_07
gump_log_06072008_03
gump_log_08072008_04
gump_log_15072008_02

Looks like there may need to be some adjustment to the run schedule to
allow for the longer runs - and/or some projects perhaps need to be
removed?

  So I'm pretty sure it is related to the mailing list config (or
  vmgump's mailer setup which probably hasn't changed in a long time
  either) and not to Gump.


  Stefan

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: notification mails for ivy-tests

[sebb]

On 11/07/2008, Stefan Bodewig [EMAIL PROTECTED] wrote:
  On Thu, 10 Jul 2008, sebb [EMAIL PROTECTED] wrote:
  
   On 10/07/2008, Maarten Coene [EMAIL PROTECTED] wrote:
Hi,
   
 I just noticed that the project ivy-tests is failing for some time 
 now, however, we didn't receive any notification mail.
 Any idea why this is the case?
  
   I noticed the same problem with JMeter.
  
   Maybe build failure detection has changed or is not working?


 I don't think it is anything on Gump's side, but more likely some
  change to the mailing list setup (Sebb would know better than me).


I don't know about other MLs, but the JMeter one certainly has not
changed in ages.


  There hasn't been any code change to Gump in months.


Gump mails are certainly being sent/received by some projects, so it
can't be a general mail problem.

Maybe the problem is with detecting whether to send an email after an
error has occurred?

As far as I can make out, the log files don't seem to record whether
or not an e-mail was sent - only if an e-mail was sent and there was
an error. Though in at least some of the cases reported as errors, the
e-mail was received anyway...

  Stefan


  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: notification mails for ivy-tests

[sebb]

On 10/07/2008, Maarten Coene [EMAIL PROTECTED] wrote:
 Hi,

  I just noticed that the project ivy-tests is failing for some time now, 
 however, we didn't receive any notification mail.
  Any idea why this is the case?

I noticed the same problem with JMeter.

Maybe build failure detection has changed or is not working?


  regards,
  Maarten





  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Suppressing maven download statistics with -B flag?

[sebb]

2008/5/2 Stefan Bodewig [EMAIL PROTECTED]:
 On Fri, 2 May 2008, sebb [EMAIL PROTECTED] wrote:

   It looks like the -B parameter suppresses these - any chance it
   could be added to the M2 command-line?

  should be easy to do once svn is writable again, I was getting annoyed
  by them as well, but not enough to bother looking up a way to supress
  them.  Will batch mode change anything else?


Well it seemed to work for me in a very simple local test.

The -B flag just means batch (non-interactive) mode, so it _ought_ to
be suitable for Gump.

BTW, I tried the property:

maven.download.meter and set it to bootstrap and silent

It did not seem to work for me with M2; perhaps that is an M1 thing

  Stefan

  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Access to test output directories

[sebb]

Is it possible to access the test output directories on gump?

For example, the Cactus build

http://vmgump.apache.org/gump/public/jakarta-cactus/cactus/index.html

has some failing tests, so it would be usefult to be able to see the
test output is at:

/srv/gump/public/workspace/jakarta-cactus/integration/ant/target/surefire-reports

but I can't work out how to get to these.

Any clues? Or is it not possible without a login?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: More info on addressing failure

[sebb]

Did yo see the following JIRA issue:




No space left on device


   Key: INFRA-1216
   URL: https://issues.apache.org/jira/browse/INFRA-1216
   Project: Infrastructure
Issue Type: Bug
Security Level: public (Regular issues)
  Reporter: Norman Maurer
  Priority: Critical


Hi all,

it seems that our gump build failed because there is no space left on
device. Here is the error:



On 20/04/07, Stefan Bodewig [EMAIL PROTECTED] wrote:

On Wed, 18 Apr 2007, Glen Daniels [EMAIL PROTECTED] wrote:

 I'd like to find out more information about the failure (of the
 addressing Gump project) attached below.

Thank you.

 The build works for me locally, and I'd like to be able to browse
 through the target/test-reports directory to read the report from
 the failing test

This is not that easy to do on a regular basis, the results of the
latest run can be found in http://vmgump.apache.org/~bodewig/

 and also if possible how I can manually kick off a build?

Without installing Gump on a machine of your own, you can't.

Right now something strange seems to be going on on vmgump since no
run since Monday has run to completion - I just haven't figured out
why, yet.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: XOM issues

[sebb]

On 08/01/07, Elliotte Harold [EMAIL PROTECTED] wrote:

Hmm, seems I'm being nagged abut XOM again. While fixing it I noticed
that it's pointing to http;//www.cafeconleche.org/XOM instead of
http://www.xom.nu/. Is there a way I can fix it to point to the latter
instead as the official web page?



Depends on what's doing the pointing ...

I assume you mean the Gump descriptor:

https://svn.apache.org/repos/asf/gump/metadata/project/xom.xml

which I have just changed.

[All committers currently have write access to the Gump descriptors]

S///

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Problem with SUEXEC

[sebb]

On 02/01/07, Dhika Cikul [EMAIL PROTECTED] wrote:

Dear,

I have problem with apache installation at my machine, i compile
apache with suexec support


[...]



anyone knows how to fix this problem??, i have tried with Apache2 and
Apache1, and get same problem



Start by sending the e-mail to the correct mailing list ... this one
is for matters relating to Gump.

Please read the instructions on the Apache HTTPD web-site:

http://httpd.apache.org/lists.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Forrest Failures

[sebb]

On 15/08/06, Gav [EMAIL PROTECTED] wrote:



 -Original Message-
 From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
 Sent: Monday, 14 August 2006 11:51 AM
 To: general@gump.apache.org
 Subject: Re: Forrest Failures

 On Sat, 12 Aug 2006, Gav [EMAIL PROTECTED]
 wrote:

  Anyway
  http://vmgump.apache.org/gump/public/forrest/forrest/index.html
 
  Any clues for me to take a look at possible cures for this, should I
  Be going to Cocoon folk or ?

 Not really, it is not Cocoon's fault that Gump doesn't support Maven2.

 Gump cannot deal with Maven2 builds and thus cannot build Cocoon.  As
 long as this doesn't change, we won't be able to build forrest or
 lenya.  It might be better to turn off nag mails for the time being.

Thanks Stefan for your reply, I have not yet had time to digest Maven at
all.
Is there a likelihood in the future that Gump would support Maven, or is
Maven intended as a replacement/alternative?


AIUI Gump currently supports Ant and Maven1 - it is Maven2 support
that is lacking.

Maven2 support would presumably (better!) be additional to Maven1.


Thanks

Gav...



 Stefan

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 --
 No virus found in this incoming message.
 Checked by AVG Free Edition.
 Version: 7.1.405 / Virus Database: 268.10.9/417 - Release Date: 8/11/2006




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Regarding gump failure of project test-ojb

[sebb]

On 15/01/06, Stefan Bodewig [EMAIL PROTECTED] wrote:
 On Sun, 15 Jan 2006, Thomas Dudziak [EMAIL PROTECTED] wrote:

  So I wanted to ask, could you perhaps run Ant with the -debug flag ?

 I'm afraid there is no easy way to do that.

  And perhaps you could send me the file velocity.log which probably
  has been produced by the run ?

 http://vmgump.apache.org/~bodewig/velocity.log, hope it helps


BTW, you can see the contents of a log file in Gump by adding
something like the following to the build.xml file:

concat
  filelist dir=. files=velocity.log /
   /concat

S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r349170 - /gump/metadata/project/jakarta-jmeter-21.xml

[sebb]

On 27/11/05, Bill Barker [EMAIL PROTECTED] wrote:

 - Original Message -
 From: [EMAIL PROTECTED]
 To: commits@gump.apache.org
 Sent: Saturday, November 26, 2005 6:21 PM
 Subject: svn commit: r349170 - /gump/metadata/project/jakarta-jmeter-21.xml


  Author: sebb
  Date: Sat Nov 26 18:21:24 2005
  New Revision: 349170
 
  URL: http://svn.apache.org/viewcvs?rev=349170view=rev
  Log:
  Try adding home to fix work ...
 

 I think that your biggest problem is that you have your mkdir / tags under
 your ant/ant tag (where they will be ignored :).  According to
 http://gump.apache.org/metadata/project.html, you need to move them to be
 under your project/project tag.


Tried that, but the classpath entries still show up as coming from

/usr/local/gump/public/workspace/jakarta-jmeter-21
rather than
/x1/gump/public/workspace/jakarta-jmeter-21

This contains the classpath details:

http://vmgump.apache.org/gump/public/jakarta-jmeter-21/jakarta-jmeter-21-test/details.html

and this shows the current directory:

http://vmgump.apache.org/gump/public/jakarta-jmeter-21/jakarta-jmeter-21-test/gump_work/build_jakarta-jmeter-21_jakarta-jmeter-21-test.html

Anyone know how to solve this?

Is /x1/gump the same as /usr/local/gump ?

S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

/usr/local/gump and /x1/gump - why the difference?

[sebb]

I'm trying to trace why JMeter fails to find all its tests under Gump.
It looks like it is a classpath naming problem.


The Gump run takes place with

user.dir=/x1/gump/public/workspace/jakarta-jmeter-21/bin

and it compiles the tests into

/x1/gump/public/workspace/jakarta-jmeter-21/build/test

The intention was to add this to the classpath, so it is specified as

work nested=build/test/

However, when the classpath is printed later, all entries are all of the form:

/usr/local/gump/public/workspace/jakarta-jmeter-21/build/test

which looks rather different.

Are these the same files?
Or are they perhaps the files from previous run?

If they are the same files, why do they have a different name?

If they are different files, then this seems to be a bug in handling
the work attribute?

S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (GUMP-134) Restore Kaffe and JDK1.5 (and Test) workspaces.

[Sebb (JIRA)]

[ 
http://issues.apache.org/jira/browse/GUMP-134?page=comments#action_12330442 ] 

Sebb commented on GUMP-134:
---

Any chance of this being addressed? We would like to use 1.5 to build JMeter

 Restore Kaffe and JDK1.5 (and Test) workspaces.
 ---

  Key: GUMP-134
  URL: http://issues.apache.org/jira/browse/GUMP-134
  Project: Gump
 Type: Task
   Components: Infrastructure
 Reporter: Adam Jack


 Need to re-enable Kaffe and JDK1.5 workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: i'm a bit lost now...

[sebb]

I think the project needs to be added to profile/gump.xml as well ...

S.
On 06/09/05, robert burrell donkin [EMAIL PROTECTED] wrote:
 it's been a while since i've done much with gump (back in the CVS days)
 and i've now discovered that i don't understand where the metadata lives
 and how it works any more. i tried adding
 http://svn.apache.org/repos/asf/gump/metadata/project/ws-jaxme-maven.xml
 in the hope that it would be picked up and run in parallel but it
 doesn't seem to have worked...
 
 help would be appreciated
 
 - robert
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.4 (GNU/Linux)
 
 iD8DBQBDHhUV1TNOdbExPeIRAjqoAJ4vX2AtUPk6064FgKYfY+8/zwiUngCeNEyD
 krMwCobrBXz43C7x5OTzkP0=
 =GfWp
 -END PGP SIGNATURE-
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (GUMP-153) Gump Metadata: links no longer work

[Sebb (JIRA)]

Gump Metadata: links no longer work
---

 Key: GUMP-153
 URL: http://issues.apache.org/jira/browse/GUMP-153
 Project: Gump
Type: Bug
 Environment: http://vmgump.apache.org/gump/public/index.html
Reporter: Sebb
Priority: Minor


The Gump meta data links no longer work, now that the metadata is in SVN.

For example:
http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-jmeter.xml
should now be:
http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-jmeter.xml

However, it would be better if the meta data link pointed to the actual file 
used by Gump for that run, rather than the current SVN contents, as that may 
have been updated since the run.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Java 1.5 on VmGump

[sebb]

Any idea when Java 1.5 will be available on Vmgump?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [GUMP] Details on JaxMe's test failure

[sebb]

On 26/08/05, Jochen Wiedmann [EMAIL PROTECTED] wrote:
 On 8/26/05, Stefan Bodewig [EMAIL PROTECTED] wrote:
 
  Doesn't look as if it worked, aren't we checking out the correct code?

If it's not obvious that the correct script is being used, you could
add a Revision property to each of the XML files involved in the
build, and then display them all at the start of the test output.

For an example of how to do this, see the jakarta-jmeter builds.

Can be very useful when you are making changes to the descriptors and
want to know which one has been picked up for the Gump run.

HTH

S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Gump presentation

[sebb]

On 17/08/05, Thomas [EMAIL PROTECTED] wrote:
 
 
 Stefan Bodewig wrote:
 
 I don't have anything to add to what Leo said, go use JIRA.
 
 BUT ...
 
 On Wed, 10 Aug 2005, Leo Simons [EMAIL PROTECTED] wrote:
 
 
 
 I'm not sure whether we decided whether Gump SoC students get svn
 accounts yet or what the policy is.
 
 
 
 At the risk of being boring - I don't think we have received a CLA,
 yet.  Thomas, have you faxed in the CLA?  If yes, do you find your
 name on this page http://people.apache.org/~jim/committers.html -
 anywhere?  If not, please (re-)submit it.  Without a CLA you'll never
 get commit access to SVN.
 
 
 
 Is there a chance that I can mail it somewhere rether then fax it? I
 don't have a fax so that would make it a lot easier for me.
 

The CLA at http://www.apache.org/licenses/icla.txt includes the address:

The Apache Software Foundation,
1901 Munsey Drive, 
Forest Hill,
MD 21050-2747,
U.S.A.

 Thomas
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Gump notifications ... are they getting through?

[sebb]

On 6/1/05, Adam  Jack [EMAIL PROTECTED] wrote:
 I am frustrated trying to debug vmgump, and e-mail notifications. I just
 don't know if they are getting through, or not. Heck, for the longest time I

I've seen a fair few Gump e-mails on commons-dev over the past few days.

Two examples today:

Adam - commons-id
dIon - configuration10 and email

I can forward them directly if you want.

HTH
S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Last Gump runs were using libgcj

[sebb]

How about creating a read-only non-executable empty /usr/bin/java file?

The warning test would need to be enhanced of course, but it might
prevent some problems from occurring.

Just a thought.

S.
On 4/26/05, Stefan Bodewig [EMAIL PROTECTED] wrote:
 On Tue, 26 Apr 2005, Leo Simons [EMAIL PROTECTED] wrote:
 
  That should do it :-D. If this gets messed up again we'll start
  receiving 4 e-mails per hour.
 
 Good idea, thanks.
 
 Stefan
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Need testers for gump3 branch + windows

[sebb]

I had similar problems. However instead of seeing messages about
$PATH, I saw the contents of $PATH, which rather messes up the
messages!

Hopefully this can be fixed?

==

I also had difficulty working out how to create the gump database - in
the end I used:

mysqladmin -u root -p create database gump
(hope I've remembered it right)

And then I used the graphical mysql administrator to create the user
(could not work out how to use this to create databases)

Got stuck with ssh, and ran out out time.

S.
On Apr 6, 2005 1:04 PM, Adam R. B. Jack [EMAIL PROTECTED] wrote:
  $ bash  gump test
  gump: line 1: /cygdrive/f/data/Python/Gump3-SVN/bin/PrintPath: No such
 file
  or directory gump: Fatal error!
 
 Ok, so I change that call to a 'which' (and I assume it is a home grown you
 are adding to avoid that dependency) and I'm getting further. Now I need to
 see why I don't have 'ssh'.
 
 regards
 
 Adam
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [GUMP@brutus]: Project dumbster (in module dumbster) failed

[sebb]

On Apr 5, 2005 12:06 AM, Jason Kitchen [EMAIL PROTECTED] wrote:
 I keep receiving the attached nag from Gump. I am not able to determine the 
 problem from the
 information given. I have verified that the project (Dumbster
 http://brutus.apache.org/gump/public/dumbster/) builds and tests fine when 
 checked out from CVS on
 various machines other than my own.
 
 So why does Gump think there is a problem here ?

Most likely, it thinks that there is a problem because there are 5 test errors.

...

 
 test:
 [junit] Running com.dumbster.smtp.AllTests
 [junit] Tests run: 16, Failures: 0, Errors: 5, Time elapsed: 0.444 sec
 
 BUILD FAILED
 /home/gump/workspaces2/public/workspace/dumbster/build.xml:89: Test 
 com.dumbster.smtp.AllTests failed
 

The build file needs to be updated to provide a bit more information
on what the errors are.

For example, add the following to the junit task in build.xml:

showoutput=true
   printsummary=withOutAndErr

S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Ant-contrib-developers] [EMAIL PROTECTED]: Project ant-contrib-test (in module ant-contrib) failed

[sebb]

See: http://brutus.apache.org/ - looks to be once a day for all but Kaffe

S.
On Sat, 12 Mar 2005 09:44:48 -0700, Dean Hiller [EMAIL PROTECTED] wrote:
 how often does this run?  I think I fixed it, but I am not sure how long I
 have to wait to know that...a day, etc.
 thanks,
 dean


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project jakarta-jmeter.xml

[sebb]

On Mon, 21 Feb 2005 08:33:29 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote:
 On 20 Feb 2005, [EMAIL PROTECTED] wrote:
 
Anakia also needs logkit..
 
 Sebb, maybe we should assemble an Anakia project that has runtime
 dependencies on all the stuff needed to run it and have all projects
 that use Anakia depend on that.

Sounds useful.

 
 jakarta-site2 used to be such a project, but since it has switched to
 XSLT instead of Anakia recently, I was planning to remove the now
 unneeded dependencies from there.
 

I was also thinking about replacing Anakia by XSLT in JMeter.
It's getting complicated to support two versions of JDom, and we can
then drop some jars.
But this will take a while, as the stylesheet is rather out of date.

 This list
 
 work nested=lib/logkit-1.2.jar/
 work nested=lib/commons-collections.jar/
 work nested=lib/velocity-1.4-dev.jar/
 work nested=legacy/jdom-b9.jar/
 
 looks complete, given that jakarta-site2 is
 
 depend project=jdom/
 depend project=jakarta-velocity/
 depend project=avalon-logkit/
 depend project=commons-collections/
 
 HEAD of velocity should work with HEAD of JDom, BTW.

Not tried that - I'll  give it a go sometime.
There's no particular need to use the CVS jars for building
documentation in Gump - though we do need them for standalone doc
creation - AFAIK Velocity have not yet released a new version that
works with JDom 1.0.

 
 Stefan
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Recent Gump Error and DefaultHandler

[sebb]

On Wed, 15 Dec 2004 17:24:53 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote:
 On Wed, 15 Dec 2004, Ceki Gülc [EMAIL PROTECTED] wrote:
[...] 
  On a different but related matter, I would love if Gump's scope (or
  mission statement) could be extended to run tests on the many
  different platforms it is deployed on.

By tests, I assume you mean unit tests and the like?

 
 That is completely in scope of Gump's mission.  Right now we run on
[...]

If Gump scope includes running tests, what is the policy on running
tests that require access to servers? I'm thinking of JMeter, but
other packages might also want to test with RMI and http/https/ftp
etc.

S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: stinking *no longer* email still flooding lists!

[sebb]

Gump sent a success message for Jmeter-dev earlier today:

[...]

Received: from Unknown (HELO [127.0.0.1]) (209.237.227.198)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 09 Dec 2004 02:39:08 -0800
Date: Thu, 09 Dec 2004 02:35:39 PST
From: Gump-build [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: Project jakarta-jmeter (in module
jakarta-jmeter) success



On Thu, 9 Dec 2004 11:57:12 -0700, Adam R. B. Jack [EMAIL PROTECTED] wrote:
 Sorry, who was spammed and when/with what? [I recently had to unsubscribe
 from the myriad of mailing lists I was on due to mental bandwidth reasons.]
 Please send on a sample.
 
 If a success message then we have a rogue branch running somewhere ('cos I
 fixed HEAD and LIVE).
 If a warning message, maybe that is a logic bug.
 If a failure, I doubt you'd be complaining.
 
 Info/insight please.
 
 regards
 
 Adam
 
 
 - Original Message -
 From: Stefano Mazzocchi [EMAIL PROTECTED]
 To: Gump [EMAIL PROTECTED]
 Sent: Thursday, December 09, 2004 8:11 AM
 Subject: stinking *no longer* email still flooding lists!
 
  I'm about ready to pull the plug on gump sending email until we figure
  out how to stop spamming people!
 
  --
  Stefano.
 
 
  -
  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]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: stinking *no longer* email still flooding lists!

[sebb]

Is this what you mean?

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2409122004, brutus:brutus-public:2409122004
Gump E-mail Identifier (unique within run) #52.

S.

On Thu, 9 Dec 2004 14:22:24 -0700, Adam R. B. Jack [EMAIL PROTECTED] wrote:
 Could I see the Gump footer (at bottom of the e-mail)? If I did correctly
 comment out success e-mails (and I would like to believe that even I can do
 that) then I need to determine why it might not be in some branch (likely
 LIVE).
 
 
 
 regards
 
 Adam
 - Original Message -
 From: sebb [EMAIL PROTECTED]
 To: Gump code and data [EMAIL PROTECTED]
 Sent: Thursday, December 09, 2004 12:43 PM
 Subject: Re: stinking *no longer* email still flooding lists!
 
  Gump sent a success message for Jmeter-dev earlier today:
 
  [...]
 
  Received: from Unknown (HELO [127.0.0.1]) (209.237.227.198)
by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 09 Dec 2004 02:39:08 -0800
  Date: Thu, 09 Dec 2004 02:35:39 PST
  From: Gump-build [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: [EMAIL PROTECTED]: Project jakarta-jmeter (in module
  jakarta-jmeter) success
 
 
 
  On Thu, 9 Dec 2004 11:57:12 -0700, Adam R. B. Jack [EMAIL PROTECTED]
 wrote:
   Sorry, who was spammed and when/with what? [I recently had to
 unsubscribe
   from the myriad of mailing lists I was on due to mental bandwidth
 reasons.]
   Please send on a sample.
  
   If a success message then we have a rogue branch running somewhere
 ('cos I
   fixed HEAD and LIVE).
   If a warning message, maybe that is a logic bug.
   If a failure, I doubt you'd be complaining.
  
   Info/insight please.
  
   regards
  
   Adam
  
  
   - Original Message -
   From: Stefano Mazzocchi [EMAIL PROTECTED]
   To: Gump [EMAIL PROTECTED]
   Sent: Thursday, December 09, 2004 8:11 AM
   Subject: stinking *no longer* email still flooding lists!
  
I'm about ready to pull the plug on gump sending email until we figure
out how to stop spamming people!
   
--
Stefano.
   
   
-
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]
  
  
 
  -
 
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: change of module names or repositories

[sebb]

On Wed, 01 Dec 2004 09:09:21 +0100, Stefan Bodewig [EMAIL PROTECTED] wrote:
 Hi all,
 
 if you change the name of a CVS module or some code base switches from
 CVS to SVN or any other change like this happens, we need to remove
 the existing working copy from brutus.
 
 In velocity's case we had:
 
  svn --quiet update --non-interactive jakarta-velocity
 svn: 'jakarta-velocity' is not a working copy

Could Gump detect the rename - or this error - automatically, and send
a suitable warning to a Gump mailing list as a backup?
 
Just wondering.

 since Gump saw the jakarta-velocity dir and thus tried an update
 instead of a checkout.
 
 Since not everybody has access to brutus, please make a lot of noise
 if you make any change like this.
 
 Cheers
 
 Stefan
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] turning off nagging until we feel gump is solid enough for that

[sebb]

On Tue, 30 Nov 2004 11:39:07 -0800, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
 I think gump's nagging is currently making more noise than signal and
 this is hurting our ability to come across as helpful instead of annoying.
 
 I propose to turn off nagging until we fix this, we are the only one
 making changes to the metadata anyway, so there is no much point in that.
 
 WDYT?

Would the nags then go to the Gump list instead?
+1 if so. 
-0 otherwise...
 
 --
 Stefano.
 
 -
 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]

Running server tests under Gump

[sebb]

I'd like to extend the JMeter unit tests to include some tests of the
samplers; however most of the samplers require a server to connect to.

Just wondering what would be the best way to go about this.

Here are some possibilities:
* run a server on a local port as part of the test suite - but how to
choose a free port number, and what server code to use - it's
expensive to start Tomcat just for a unit test or three.
* connect to one of the Apache/Jakarta sites (for http/ftp at least)
* if external connections are to be avoided (apart from cvs/svn, of
course), perhaps the gump could provide a set of local test servers.

Or indeed is it a good idea to run such tests under Gump at all?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EMAIL PROTECTED]: Project cocoon-block-jms (in module cocoon) failed

[sebb]

On Tue, 9 Nov 2004 17:08:36 +, sebb [EMAIL PROTECTED] wrote:
 On Tue, 09 Nov 2004 10:33:26 -0500, Stefano Mazzocchi
 
 
 [EMAIL PROTECTED] wrote:
  Stefan Bodewig wrote:
 
 
   On Mon, 08 Nov 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
  
  
  Geoff Howard wrote:
  
  
  I find it hard to believe the jms spec has changed, though I
  suppose this is possible.
  
  
   Which version does geronimo-* implement?  Maybe it is a change between
   1.0.2 (the version of JMS we had before Niclas changed it to the
   geronimo version) and 1.1 - which seems to be the current version.
  
   Any reason we use Geronimo snapshots instead of the official Sun
   jars, BTW?
 
  no really. We shipt it with geronimo's and that compiles so I thought
  that was going to be better, but nope.
 
  If we identified there is a API change between 1.0.2 and 1.1, I'd rather
  have cocoon update to the latest JMS API rather than having to different
  packages in gump since it seems that cocoon is the only one having that
  problem anyway.
 
 Not quite - JMeter is also failing to find JMS, but as it's optional,
 no error is generated.
 
 See:
 
 http://brutus.apache.org/gump/public/jakarta-jmeter/jakarta-jmeter/gump_work/build_jakarta-jmeter_jakarta-jmeter.html
 
 ...
 
 /usr/local/gump/packages/jms1.0.2/lib/jms.jar ...
 
 ...
 
 jms-message:
  [echo] Classes for JMS support not found in classpath
 
 I don't understand why the JMS jar is not being found - hopefully the
 latest JMS might solve this...
 

Duh! This is a JMeter build.xml issue.
Gump builds use a different target in the build file, and set the
properties directly, rather than checking for a class name ...

 
  --
  Stefano.
 
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EMAIL PROTECTED]: Project cocoon-block-jms (in module cocoon) failed

[sebb]

On Tue, 09 Nov 2004 10:33:26 -0500, Stefano Mazzocchi
[EMAIL PROTECTED] wrote:
 Stefan Bodewig wrote:
 
 
  On Mon, 08 Nov 2004, Stefano Mazzocchi [EMAIL PROTECTED] wrote:
 
 
 Geoff Howard wrote:
 
 
 I find it hard to believe the jms spec has changed, though I
 suppose this is possible.
 
 
  Which version does geronimo-* implement?  Maybe it is a change between
  1.0.2 (the version of JMS we had before Niclas changed it to the
  geronimo version) and 1.1 - which seems to be the current version.
 
  Any reason we use Geronimo snapshots instead of the official Sun
  jars, BTW?
 
 no really. We shipt it with geronimo's and that compiles so I thought
 that was going to be better, but nope.
 
 If we identified there is a API change between 1.0.2 and 1.1, I'd rather
 have cocoon update to the latest JMS API rather than having to different
 packages in gump since it seems that cocoon is the only one having that
 problem anyway.

Not quite - JMeter is also failing to find JMS, but as it's optional,
no error is generated.

See:

http://brutus.apache.org/gump/public/jakarta-jmeter/jakarta-jmeter/gump_work/build_jakarta-jmeter_jakarta-jmeter.html

...

/usr/local/gump/packages/jms1.0.2/lib/jms.jar ...

...

jms-message:
 [echo] Classes for JMS support not found in classpath


I don't understand why the JMS jar is not being found - hopefully the
latest JMS might solve this...

 
 --
 Stefano.
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TEST-xxx files available?

[sebb]

Or you might be able to use something like JMeter uses in its build.xml:

concat
  filelist dir=bin files=jmeter-test.log /
/concat

Some of the output of the test run is logged to this file, which is
otherwise not available in a remote Gump.

HTH

On Tue, 12 Oct 2004 07:56:39 -0600, Adam R. B. Jack [EMAIL PROTECTED] wrote:
  Is there any way we can have a look at the TEST output for
 
 http://brutus.apache.org/gump/public/excalibur/excalibur-event-impl/gump_work/build_excalibur_excalibur-event-impl.html
 
 
 If you add this,  http://gump.apache.org/metadata/project.html#junitreport,
 Gump ought show you the files/contents.
 
 regards
 
 Adam
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [GUMP@brutus]: gump/gump-test failed

[sebb]

On Mon, 04 Oct 04 01:05:50 PDT, Adam Jack [EMAIL PROTECTED] wrote:
 To whom it may engage...

[...]
 
 Project gump-test has an issue affecting its community integration, and has been 
 outstanding for 12L runs.

12 L ?

What the L's this mean?

S.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project jakarta-jmeter.xml

[sebb]

On 20 Sep 2004 09:18:33 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 bodewig 2004/09/20 02:18:33
 
   Modified:project  jakarta-jmeter.xml
   Log:
   remove broken project references
 
   Revision  ChangesPath
   1.106 +12 -10gump/project/jakarta-jmeter.xml
 
   Index: jakarta-jmeter.xml
   ===
   RCS file: /home/cvs/gump/project/jakarta-jmeter.xml,v
   retrieving revision 1.105
   retrieving revision 1.106
   diff -u -r1.105 -r1.106
   --- jakarta-jmeter.xml10 Sep 2004 14:01:01 -  1.105
   +++ jakarta-jmeter.xml20 Sep 2004 09:18:32 -  1.106
   @@ -85,9 +85,11 @@
 
depend project=commons-collections/
depend project=jtidy /
   -depend project=excalibur-compatibility /
depend project=excalibur-logger /
   +!-- gone, no idea what to replace them with
   +depend project=excalibur-compatibility /
depend project=excalibur-i18n /
   +--

Perhaps there needs to be an archive version of such items in Gump.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project jakarta-jmeter.xml

[sebb]

On Mon, 20 Sep 2004 13:17:49 +0200, Stephen McConnell
[EMAIL PROTECTED] wrote:
 
 
  -Original Message-
  From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
  Sent: 20 September 2004 13:10
  To: [EMAIL PROTECTED]
  Subject: Re: cvs commit: gump/project jakarta-jmeter.xml
 
  On Mon, 20 Sep 2004, sebb [EMAIL PROTECTED] wrote:
   On 20 Sep 2004 09:18:33 -, [EMAIL PROTECTED]
   [EMAIL PROTECTED] wrote:
 remove broken project references
 -depend project=excalibur-compatibility /
  depend project=excalibur-logger /
 +!-- gone, no idea what to replace them with
 +depend project=excalibur-compatibility /
  depend project=excalibur-i18n /
 +--
  
   Perhaps there needs to be an archive version of such items in Gump.
 
  Probably.
 
  Are the latest excalibur releases from Avalon the ones to look at?  I
  surely can't answer this, but you (as a client of those libs) should
  know.
 
 All of the avalon stuff is good with full endorsed releases.

OK, thanks, I'll check this out.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: gump/project jakarta-jmeter.xml

[sebb]

On Mon, 20 Sep 2004 13:02:16 +0200, Stephen McConnell
[EMAIL PROTECTED] wrote:
 
 
  -Original Message-
  From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
  Sent: 20 September 2004 12:57
  To: Gump code and data
  Subject: Re: cvs commit: gump/project jakarta-jmeter.xml
 
  On Monday 20 September 2004 18:48, sebb wrote:
 
  +!-- gone, no idea what to replace them with
  +depend project=excalibur-compatibility /
   depend project=excalibur-i18n /
 
   Perhaps there needs to be an archive version of such items in Gump.
 
  By the way, I think I saw something about using an i18n package at
  CodeHaus or
  some other similar external source.
 
 
 There is also the following (maintained) version of i18n.
 
 http://www.apache.org/dist/avalon/avalon-util/jars/
 
 You just need to switch package names to:
 
   org.apache.avalon.util.i18n
 

Just had a brief look around the Avalon web-site, and there seems to
be no mention of the status of these jars...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: gump/project jakarta-jmeter.xml

[sebb]

sebb2004/06/21 14:35:00

  Modified:project  jakarta-jmeter.xml
  Log:
  Make xpp and xstream separate sub-projects
  
  Revision  ChangesPath
  1.102 +32 -16gump/project/jakarta-jmeter.xml
  
  Index: jakarta-jmeter.xml
  ===
  RCS file: /home/cvs/gump/project/jakarta-jmeter.xml,v
  retrieving revision 1.101
  retrieving revision 1.102
  diff -u -r1.101 -r1.102
  --- jakarta-jmeter.xml20 Jun 2004 01:48:04 -  1.101
  +++ jakarta-jmeter.xml21 Jun 2004 21:35:00 -  1.102
  @@ -97,11 +97,10 @@
   work nested=build/htmlparser/
   work nested=build/jorphan/
   
  -!-- Not available as Gump projects --
  -work nested=lib/xpp3-1.1.3.4.D.jar/
  -work nested=lib/xstream-1.0.1.jar/
  -
  -!-- Allow http to build: --
  +depend project=xpp3/
  +depend project=xstream/
  +
  +!-- Allow http to build: --
   work nested=build/components/
   
   !-- Allow Monitor to build --
  @@ -113,8 +112,25 @@
   regexp pattern=/BUILD FAILED/ subject=JMeter Build Failure/
   /nag
 /project
  -
  -  project name=jakarta-jmeter-cvs
  +  
  +  project name=xpp3
  + url href=http://www.extreme.indiana.edu/xgws/xsoap/xpp//
  + description
  + Xml Pull Parser (in short XPP) is a streaming pull XML parser
  + and should be used when there is a need to process quickly and 
efficiently 
  + all input elements.
  + /description
  + jar name=lib/xpp3-1.1.3.4.D.jar id=xpp3/
  +  /project
  +  
  +  project name=xstream
  + url href=http://xstream.codehaus.org//
  + descriptionXStream is a simple library to serialize objects to XML and back 
again
  + /description
  +jar name=lib/xstream-1.0.1.jar id=xstream/
  +  /project
  +  
  + project name=jakarta-jmeter-cvs
   !-- Build JMeter from CVS versions of dependencies --
   packageorg.apache.jmeter/package
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: gump/project jakarta-jmeter-20.xml

[sebb]

sebb2004/06/18 03:55:15

  Modified:project  jakarta-jmeter-20.xml
  Log:
  Fix e-mail sender name
  
  Revision  ChangesPath
  1.7   +7 -7  gump/project/jakarta-jmeter-20.xml
  
  Index: jakarta-jmeter-20.xml
  ===
  RCS file: /home/cvs/gump/project/jakarta-jmeter-20.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jakarta-jmeter-20.xml 24 May 2004 09:43:52 -  1.6
  +++ jakarta-jmeter-20.xml 18 Jun 2004 10:55:15 -  1.7
  @@ -109,7 +109,7 @@
   jar name=NOTICE /
   jar name=INSTALLING /
   
  -nag from=Sebb lt;[EMAIL PROTECTED]gt;
  +nag from=Gump-build lt;[EMAIL PROTECTED]gt;
to=[EMAIL PROTECTED]
   regexp pattern=/BUILD FAILED/ subject=JMeter CVS Build Failure/
   /nag
  @@ -174,7 +174,7 @@
   work nested=lib/ext/ApacheJMeter_monitors.jar/
   work nested=lib/ext/ApacheJMeter_tcp.jar/
   
  -nag from=Sebb lt;[EMAIL PROTECTED]gt;
  +nag from=Gump-build lt;[EMAIL PROTECTED]gt;
to=[EMAIL PROTECTED]
   regexp pattern=/FAILURES!!!|OK \(0 tests\)/ subject=JMeter Unit Test 
Failure/
   /nag
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: gump/project jakarta-jmeter-20.xml

[sebb]

sebb2004/05/24 02:43:52

  Modified:project  jakarta-jmeter-20.xml
  Log:
  Missed the obvious fix - change the cvs module name!
  
  Revision  ChangesPath
  1.6   +7 -7  gump/project/jakarta-jmeter-20.xml
  
  Index: jakarta-jmeter-20.xml
  ===
  RCS file: /home/cvs/gump/project/jakarta-jmeter-20.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jakarta-jmeter-20.xml 22 May 2004 09:30:49 -  1.5
  +++ jakarta-jmeter-20.xml 24 May 2004 09:43:52 -  1.6
  @@ -14,7 +14,7 @@
 See the License for the specific language governing permissions and
 limitations under the License.
   --
  -module name=jakarta-jmeter tag=rel-2_0
  +module name=jakarta-jmeter-20 tag=rel-2_0
   !-- Version $Revision$ Last updated $Date$ --
 url href=http://jakarta.apache.org/jmeter/; /
 description
  @@ -22,7 +22,7 @@
   Release branch 2_0
 /description
   
  -  cvs repository=jakarta /
  +  cvs repository=jakarta module=jakarta-jmeter/
 
   
 project name=jakarta-jmeter-20-cvs
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: gump/project jakarta-jmeter-20.xml

[sebb]

sebb2004/05/22 02:11:21

  Modified:project  jakarta-jmeter-20.xml
  Log:
  Cannot use different module name as it is the CVS module name as well
  
  Revision  ChangesPath
  1.4   +8 -8  gump/project/jakarta-jmeter-20.xml
  
  Index: jakarta-jmeter-20.xml
  ===
  RCS file: /home/cvs/gump/project/jakarta-jmeter-20.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jakarta-jmeter-20.xml 21 May 2004 10:07:51 -  1.3
  +++ jakarta-jmeter-20.xml 22 May 2004 09:11:21 -  1.4
  @@ -57,8 +57,8 @@
   option project=beanshell ids=bsh-core/
   option project=jakarta-bsf/
   
  -!-- Try to ensure that cvs builds after jmeter --
  -option project=jakarta-jmeter
  +!-- Try to ensure that this builds after main jmeter build --
  +option project=jakarta-jmeter-test
noclasspath/
   /option
   
  @@ -127,7 +127,7 @@
   
   depend project=ant /
   
  -depend project=jakarta-jmeter-cvs ids=none
  +depend project=jakarta-jmeter-20-cvs ids=none
noclasspath/
   /depend
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: gump/project jakarta-jmeter-20.xml

[sebb]

sebb2004/05/22 02:30:50

  Modified:project  jakarta-jmeter-20.xml
  Log:
  
  
  Revision  ChangesPath
  1.5   +6 -6  gump/project/jakarta-jmeter-20.xml
  
  Index: jakarta-jmeter-20.xml
  ===
  RCS file: /home/cvs/gump/project/jakarta-jmeter-20.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jakarta-jmeter-20.xml 22 May 2004 09:11:21 -  1.4
  +++ jakarta-jmeter-20.xml 22 May 2004 09:30:49 -  1.5
  @@ -14,7 +14,7 @@
 See the License for the specific language governing permissions and
 limitations under the License.
   --
  -module name=jakarta-jmeter-20 tag=rel-2_0
  +module name=jakarta-jmeter tag=rel-2_0
   !-- Version $Revision$ Last updated $Date$ --
 url href=http://jakarta.apache.org/jmeter/; /
 description
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: gump/server brutus.xml

[sebb]

sebb2004/05/21 03:19:12

  Modified:server   brutus.xml
  Log:
  Brutus runs seem to have moved
  
  Revision  ChangesPath
  1.4   +1 -1  gump/server/brutus.xml
  
  Index: brutus.xml
  ===
  RCS file: /home/cvs/gump/server/brutus.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- brutus.xml29 Mar 2004 14:11:25 -  1.3
  +++ brutus.xml21 May 2004 10:19:12 -  1.4
  @@ -18,6 +18,6 @@
   server name=brutus type=python status=up
 attributionThe Apache Software Foundation/attribution
 titleBrutus/title
  -  urlhttp://brutus.apache.org/gump/public/url
  +  urlhttp://brutus.apache.org:8080/gump/url
 sitehttp://gump.apache.org/site
   /server
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]