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

[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

[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  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  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  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

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

[sebb]

On 22 September 2011 10:42, Stefan Bodewig  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

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 
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: Help needed with ASF Branding Requirements

[sebb]

On 4 June 2011 06:32, Stefan Bodewig  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  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,   wrote:
> Author: bodewig
> Date: Mon Apr 11 06:24:37 2011
> New Revision: 1090947
>
> URL: http://svn.apache.org/viewvc?rev=1090947&view=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=1090947&r1=1090946&r2=1090947&view=diff
> ==
> --- gump/metadata/profile/gump.xml (original)
> +++ gump/metadata/profile/gump.xml Mon Apr 11 06:24:37 2011
> @@ -111,11 +111,7 @@
>   
>   
>   
> -
>   
>   
>   
> @@ -318,6 +314,7 @@
>   
>
>   
> +  
>   
>   
>   
> @@ -342,6 +339,7 @@
>   
>   
>   
> +  
>   
>
>  
> @@ -383,11 +381,11 @@
>   
>   
>   
> -  
>
>  
>   
> -
> +  
> +  
>
>  
>   
> @@ -413,6 +411,7 @@
>   
>   
>   
> +  
>   
>   
>   
> @@ -481,7 +480,7 @@
>   
>   
>   
> -  
> +  
>   
>   
>   
> @@ -507,6 +506,7 @@
>   
>   
>   
> +  
>   
>   
>   
> @@ -519,6 +519,7 @@
>   
>   
>   
> +  
>   
>   
>   
>
>
>

-
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  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  wrote:
> On 18 January 2011 11:20, Stefan Bodewig  wrote:
>> On 2011-01-13, sebb wrote:
>>
>>> On 10 January 2011 20:26, sebb  wrote:
>>>> On 10 January 2011 12:23, Stefan Bodewig  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  task that runs the test.

Adding the Xalan jars to the test run using 
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  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  wrote:
> On 2011-01-13, sebb wrote:
>
>> On 10 January 2011 20:26, sebb  wrote:
>>> On 10 January 2011 12:23, Stefan Bodewig  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  wrote:
> On 10 January 2011 12:23, Stefan Bodewig  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  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  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,   wrote:
> Author: billbarker
> Date: Sat Dec 11 23:26:04 2010
> New Revision: 1044741
>
> URL: http://svn.apache.org/viewvc?rev=1044741&view=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  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,   wrote:
> Author: bodewig
> Date: Mon Nov 15 04:59:23 2010
> New Revision: 1035144
>
> URL: http://svn.apache.org/viewvc?rev=1035144&view=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=1035144&r1=1035143&r2=1035144&view=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 @@
>     
>     
>     
> -    
>     
>     
>     
>
>
>

-
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  wrote:
> If the pattern has to be a regular expression, it should be:
> 

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  wrote:
>
>> From: Stefan Bodewig 
>> 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,  
>> wrote:
>>
>> >> I don't know why wildcards sometimes don't seem to
>> work
>>
>> >> -    > name="target/checkstyle-*[0-9T].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: svn commit: r1001631 - /gump/metadata/project/checkstyle.xml

[sebb]

On 27 September 2010 11:48, Stefan Bodewig  wrote:
> On 2010-09-27, sebb wrote:
>
>> On 27 September 2010 10:07,   wrote:
>
>>> I don't know why wildcards sometimes don't seem to work
>
>>> -    >> +    
>> 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 10:07,   wrote:
> Author: bodewig
> Date: Mon Sep 27 09:07:30 2010
> New Revision: 1001631
>
> URL: http://svn.apache.org/viewvc?rev=1001631&view=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=1001631&r1=1001630&r2=1001631&view=diff
> ==
> --- gump/metadata/project/checkstyle.xml (original)
> +++ gump/metadata/project/checkstyle.xml Mon Sep 27 09:07:30 2010
> @@ -37,7 +37,7 @@
>     
>     
>
> -     +              id="checkstyle"/>
>
>     
>
>
>

-
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  wrote:
> On 2010-09-14, sebb wrote:
>
>> On 13 September 2010 20:41, Stefan Bodewig  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  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

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

[sebb]

On 14 September 2010 18:49, Stefan Bodewig  wrote:
> On 2010-09-14,  wrote:
>
>> -    
>> +    
>
> Uhm, no.  I've reverted that part.

Sorry ...

> The commons-beanutils project has a  element that points at
> beanutils/dist - that's why the .. was needed -  and  are
> resolved relative to .
>
> commons-jci doesn't have a  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

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  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: Problem with collections test dependency

[sebb]

On 13 September 2010 20:41, Stefan Bodewig  wrote:
> On 2010-09-13, sebb wrote:
>
>> On 13 September 2010 05:11, Stefan Bodewig  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=revision&revision=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  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

Re: Problem with collections test dependency

[sebb]

On 13 September 2010 05:11, Stefan Bodewig  wrote:
> On 2010-09-13, sebb wrote:
>
>> On 13 September 2010 03:36, Bill Barker  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 03:36, Bill Barker  wrote:
>
>
> --
> From: "sebb" 
> Sent: Sunday, September 12, 2010 5:00 AM
> To: 
> 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

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: Update bouncycastle version?

[sebb]

On 30/06/2010, Stefan Bodewig  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: Self-Description of Gump

[sebb]

On 26/05/2010, Stefan Bodewig  wrote:
> Hi all,
>
>  so far we are getting away with a much thinner kind of board reports
>  than is required by many other projects - this is probably due in part
>  to the fact that Gump is an old TLP and in part that its PMC is composed
>  of ASF members almost exclusively, so we get some trust.
>
>  One thing the board usually asks each reporting project to provide is a
>  one paragraph description of the project and I'd like to provide that
>  starting with the next report due in about three weeks.  The same
>  paragraph could be used to describe Gump at ci.apache.org.
>
>  I've drafted something in the wiki page for the next board report[1],
>  please review it and modify as you see fit.  Yes, I know I've written
>  two paragraphs ;-)

Looks good to me, but it would be helpful to augment the version at
ci.apache.org with details on which build tools are supported - e.g.
Ant, Maven, Maven2 etc. Not sure that is necessary for the Board
report (except when the list changes).

>  Stefan
>
>  [1] http://wiki.apache.org/gump/Drafts/BoardReports/20100616
>
>  -
>  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  wrote:
> Author: bodewig
>  Date: Fri Apr 16 14:27:48 2010
>  New Revision: 934914
>
>  URL: http://svn.apache.org/viewvc?rev=934914&view=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=934914&r1=934913&r2=934914&view=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 @@
>  
>  
>  
>  -
>  
>  
>  
>  @@ -117,7 +116,6 @@
>  
>  
>  
>  -
>  
>  
>  
>
>  Modified: gump/metadata/project/jakarta-slide.xml
>  URL: 
> http://svn.apache.org/viewvc/gump/metadata/project/jakarta-slide.xml?rev=934914&r1=934913&r2=934914&view=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 @@
>  
>  
>  
>  -
>  
>  
>  
>
>
>

-
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  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: Access to Maven settings for BSF Gump build

[sebb]

On 01/04/2010, Jörg Schaible  wrote:
> Hi Brett,
>
>  Brett Randall wrote:
>
>
> > 
>  >>
>  >> 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
>  >>
>  > 
>  >
>  > 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
>  > 
>  > c6817d078ad972bcf1716e05e4c7f52f  -
>  > bsf-engines$ mvn clean install && unzip -p
>  > target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class |
>  > md5sum
>  > 
>  > 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  wrote:
> sebb wrote:
>
>  > On 31/03/2010, Jörg Schaible  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 31/03/2010, Jörg Schaible  wrote:
> Hi Brett,
>
>  Brett Randall wrote:
>
>
> > On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible 
>  > wrote:
>  >> sebb wrote:
>  >>
>  >>> On 30/03/2010, Jörg Schaible  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 30/03/2010, Jörg Schaible  wrote:
> sebb wrote:
>
>  > On 30/03/2010, sebb  wrote:
>  >> On 30/03/2010, Jörg Schaible  wrote:
>  >>  > sebb wrote:
>  >>  >
>  >>  >  > On 30/03/2010, Jörg Schaible  wrote:
>  >>  >  >> sebb wrote:
>  >>  >  >>
>  >>  >  >>  > On 30/03/2010, Jörg Schaible  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
>  >>  >  >>  > 
>  >>  >  >>  >
>  >>  >  >>  >  [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:
>  >&

Re: Access to Maven settings for BSF Gump build

[sebb]

On 30/03/2010, sebb  wrote:
> On 30/03/2010, Jörg Schaible  wrote:
>  > sebb wrote:
>  >
>  >  > On 30/03/2010, Jörg Schaible  wrote:
>  >  >> sebb wrote:
>  >  >>
>  >  >>  > On 30/03/2010, Jörg Schaible  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
>  >  >>  > 
>  >  >>  >
>  >  >>  >  [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  wrote:
> sebb wrote:
>
>  > On 30/03/2010, Jörg Schaible  wrote:
>  >> sebb wrote:
>  >>
>  >>  > On 30/03/2010, Jörg Schaible  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
>  >>  > 
>  >>  >
>  >>  >  [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, Jörg Schaible  wrote:
> sebb wrote:
>
>  > On 30/03/2010, Jörg Schaible  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
>  > 
>  >
>  >  [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  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


 [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

> 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.

>  - 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  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 



  
/srv/gump/public/workspace/mvnlocalrepo

  gump-central
  Gump proxying central
  http://localhost:8192/maven2
  central


  gump-apache.snapshots
  Gump proxying apache.snapshots
  http://localhost:8192/repo/m2-snapshot-repository
  apache.snapshots


  gump-maven2-repository.dev.java.net
  Gump proxying maven2-repository.dev.java.net
  http://localhost:8192/maven/2
  maven2-repository.dev.java.net

 cut here ===

>  Thanks
>
> Brett
>

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

[jira] Created: (GUMP-160) Mail message differs significantly from log and does not include the Error !

[Sebb (JIRA)]

Mail message differs significantly from log and does not include the Error !


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


The mail message that is sent when a test error occurs often does not include 
the error details.

See sample attachments for the same run; a large section of the test run is 
omitted.

Ideally the failure lines should be included, but if that is not possible, the 
mail message should make it clearer where the pruning takes place.


-- 
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: r923057 - /gump/metadata/project/commons-proper.xml

[sebb]

On 15/03/2010, Stefan Bodewig  wrote:
> On 2010-03-15, sebb  wrote:
>
>  > On 15/03/2010, bode...@apache.org  wrote:
>
>
> >>  URL: http://svn.apache.org/viewvc?rev=923057&view=rev
>  >>  Log:
>  >>  canonical property to skip tests in mvn
>
>
> >>  -  
>  >>  + 
>
>  > 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: svn commit: r923057 - /gump/metadata/project/commons-proper.xml

[sebb]

On 15/03/2010, bode...@apache.org  wrote:
> Author: bodewig
>  Date: Mon Mar 15 05:23:18 2010
>  New Revision: 923057
>
>  URL: http://svn.apache.org/viewvc?rev=923057&view=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=923057&r1=923056&r2=923057&view=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 @@
>  Commons I/O Utility Package
>
>  
>  -  
>  +  

maven.test.skip.exec is deprecated:

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

which is why I used skipTests.

>  
>
>  
>
>
>

-
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  wrote:
> On 02/10/2009, Leo Simons  wrote:
>  > Hey sebb,
>  >
>  >
>  >  On Sat, Sep 19, 2009 at 10:50 AM, sebb  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 02/10/2009, Leo Simons  wrote:
> Hey sebb,
>
>
>  On Sat, Sep 19, 2009 at 10:50 AM, sebb  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 21/09/2009, Stefan Bodewig  wrote:
> On 2009-09-21, sebb  wrote:
>
>  > On 21/09/2009, Stefan Bodewig  wrote:
>  >> On 2009-09-19, sebb  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  so I'd say stick with .
>
>
>  > Surely  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

Re: How to depend on legacy projects?

[sebb]

On 21/09/2009, Stefan Bodewig  wrote:
> On 2009-09-19, sebb  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  so I'd say stick with .
>

Surely  requires that the package be stored within SVN?
Or am I missing something here?

>  > 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?
>
>
> No.  This is really something the build system must do, say via Ivy or
>  the Maven Ant Tasks, but then it would still require  elements
>  since Ant running with build.sysclasspath=only would ignore any in
>  build-file  using the downloaded jars.
>
>
>  > JMeter also depends on jCharts 0.75 and htmlparser,
>
>
> What Bill said.
>
>  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 .

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  wrote:
> On 2009-09-09, Stefan Bodewig  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  wrote:
> On 2009-09-08, sebb  wrote:
>
>  > On 08/09/2009, Stefan Bodewig  wrote:
>  >> On 2009-09-08,  wrote:
>
>  >>> No longer using Ant build now that Jexl 2.0 is the trunk version
>  >>> Initial stab at M2 build
>
>  >>>>
>  >>>>
>
>  >>  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  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: svn commit: r812413 - /gump/metadata/project/commons-proper.xml

[sebb]

On 08/09/2009, Stefan Bodewig  wrote:
> On 2009-09-08,  wrote:
>
>  > No longer using Ant build now that Jexl 2.0 is the trunk version
>  > Initial stab at M2 build
>
>  >+
>  >+
>
>  If anybody depends on it and is supposed to use the generated jar, yes.

It's used by Jelly.

But what should it be?


>  Otherwise it is optional.
>
>  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  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  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/3 Stefan Bodewig <[EMAIL PROTECTED]>:
> On Fri, 2 May 2008, sebb <[EMAIL PROTECTED]> wrote:
>
>  > 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.
>
>  It is in now and we should see the effect on the next run on Helios,
>  if everything looks OK I'll merge it over to the live branch which is
>  used on vmgump.
>

OK thanks.

>  > The -B flag just means batch (non-interactive) mode, so it _ought_
>  > to be suitable for Gump.
>
>  I didn't perform any research beyond what mvn --help says and I really
>  don't have any idea what the switch is going to do.

Same here .

> The web-site doesn't say a word about it.  Let's hope it is exactly what we 
> need 8-)
>

I'll probably raise a docn. bug report.

>
>  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: 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]

Suppressing maven download statistics with -B flag?

[sebb]

Gump logs are filled with messy Maven2 download stats:

4/173K
8/173K
12/173K

etc.

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

S///

-
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 

> 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: xalan xsltc and bcel

[sebb]

On 07/06/06, Dion Gillard <[EMAIL PROTECTED]> wrote:

Wouldn't generating an ant build file work as well?

On 6/7/06, Bill Barker <[EMAIL PROTECTED]> wrote:
>
> Pretty much, the only way is to jump in and contribute to supporting Maven
> 2 on Gump ;).  Otherwise, if BCEL isn't going to continue to support either
> a Maven 1 build or an Ant build, eventualy we'll probably just do the same


Yes 

;-)


> thing to BCEL and it's dependants as we did to Cocoon, and nuke it :).
>
>
> -Original Message-
> From: [EMAIL PROTECTED] on behalf of Torsten Curdt
> Sent: Wed 6/7/2006 1:31 AM
> To: general@gump.apache.org
> Subject: xalan xsltc and bcel
>
> Guys,
>
> I probably should know by now but... We just recently switched bcel
> trunk to maven2 and juggled a bit with the directory layout. So gump
> keeps failing on xalan because of the xalan -> bcel dependency.
>
> Where do I fix this?
>
> cheers
> --
> Torsten
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> This message is intended only for the use of the person(s) listed above as
> the intended recipient(s), and may contain information that is PRIVILEGED
> and CONFIDENTIAL.  If you are not an intended recipient, you may not read,
> copy, or distribute this message or any attachment. If you received this
> communication in error, please notify us immediately by e-mail and then
> delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
http://www.multitask.com.au/people/dion/
Chuck Norris sleeps with a night light. Not because Chuck Norris is afraid
of the dark, but because the dark is afraid of Chuck Norris




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

Re: xsl:include not working properly under Gump

[sebb]

OK, thanks - I've disabled the Gump fix.
[I'll remove it entirely later]

S.
On 06/06/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:

Hello Sebb,

I broke xsl:include with a change in the XSLTTask in ant.
I will fix this evening.

Regards,

Antoine
>  Original-Nachricht 
> Datum: Tue, 6 Jun 2006 18:05:13 +0100
> Von: sebb <[EMAIL PROTECTED]>
> An: Jakarta General List , Gump code and data 

> Betreff: xsl:include not working properly under Gump
>
> On 03/06/06, sebb <[EMAIL PROTECTED]> wrote:
> > On 03/06/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > > To whom it may engage...
> > >
> > > news-gen:
> > > [mkdir] Created dir:
> /x1/gump/public/workspace/jakarta-site2/target/news-gen
> > >  [xslt] Processing
> /x1/gump/public/workspace/jakarta-site2/news.xml
> to /x1/gump/public/workspace/jakarta-site2/docs/site/rss.xml
> > >  [xslt] Loading stylesheet
> /x1/gump/public/workspace/jakarta-site2/xdocs/stylesheets/news2content.xsl
> > >  [xslt]
> /x1/gump/public/workspace/jakarta-site2/news2content.xsl:28:36: Error! Had
> IO Exception with stylesheet file: common.xsl Cause:
> java.io.FileNotFoundException:
> /x1/gump/public/workspace/jakarta-site2/common.xsl (No such file or
> directory)
> >
> > Something odd going on here. The loaded style-sheet is
> >
> > .../jakarta-site2/xdocs/stylesheets/news2content.xsl
> >
> > but the error message quotes:
> >
> > .../jakarta-site2/news2content.xsl
> >
> > This may explain why it is looking for
> >
> > .../jakarta-site2/common.xsl
> >
> > rather than
> >
> > .../jakarta-site2/xdocs/stylesheets/common.xsl
> >
> > I'm going to try:
> > - deleting .../jakarta-site2/news2content.xsl just in case there is a
> copy there
> > - copying common.xsl into top-level
> >
> Copying common.xsl to the top-level works. But that in turn then
> fails, because it also uses xsl:import. That can be fixed. But then
> later xslt transformations fail. Etc.
>
> According to the documentation I've read, relative references in
> xsl:import tags should be resolved with respect to the parent
> document.
>
> However, when run under Gump, the references seem to be resolved
> relative to the current working directory, which stops the build from
> working.
>
> Does anyone know how to fix this?
> Is it perhaps a feature of the xslt processor that is used?
> How do I find out what is being used?
>
> Note that the build script works fine under Java 1.4 and 1.5 when run
> outside Gump.
>
> Sebastian
>
> -
> 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]

xsl:include not working properly under Gump

[sebb]

On 03/06/06, sebb <[EMAIL PROTECTED]> wrote:

On 03/06/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> To whom it may engage...
>
> news-gen:
> [mkdir] Created dir: 
/x1/gump/public/workspace/jakarta-site2/target/news-gen
>  [xslt] Processing /x1/gump/public/workspace/jakarta-site2/news.xml to 
/x1/gump/public/workspace/jakarta-site2/docs/site/rss.xml
>  [xslt] Loading stylesheet 
/x1/gump/public/workspace/jakarta-site2/xdocs/stylesheets/news2content.xsl
>  [xslt] /x1/gump/public/workspace/jakarta-site2/news2content.xsl:28:36: 
Error! Had IO Exception with stylesheet file: common.xsl Cause: 
java.io.FileNotFoundException: /x1/gump/public/workspace/jakarta-site2/common.xsl 
(No such file or directory)

Something odd going on here. The loaded style-sheet is

.../jakarta-site2/xdocs/stylesheets/news2content.xsl

but the error message quotes:

.../jakarta-site2/news2content.xsl

This may explain why it is looking for

.../jakarta-site2/common.xsl

rather than

.../jakarta-site2/xdocs/stylesheets/common.xsl

I'm going to try:
- deleting .../jakarta-site2/news2content.xsl just in case there is a copy there
- copying common.xsl into top-level



Copying common.xsl to the top-level works. But that in turn then
fails, because it also uses xsl:import. That can be fixed. But then
later xslt transformations fail. Etc.

According to the documentation I've read, relative references in
xsl:import tags should be resolved with respect to the parent
document.

However, when run under Gump, the references seem to be resolved
relative to the current working directory, which stops the build from
working.

Does anyone know how to fix this?
Is it perhaps a feature of the xslt processor that is used?
How do I find out what is being used?

Note that the build script works fine under Java 1.4 and 1.5 when run
outside Gump.

Sebastian

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

Re: [EMAIL PROTECTED]: Project xml-batik (in module xml-batik) failed

[sebb]

On 24/03/06, Cameron McCormack <[EMAIL PROTECTED]> wrote:
> Hi Bill.
>
> Bill Barker:
> > You would just have to change the Gump descriptor xml-batik.xml and replace
> >   
> > with
> >   
>
> Are there some instructions on how I can change this?  Is it accessible
> from SVN somewhere?

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

All committers have access (or should )

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

Re: Help for WSRP4J

[sebb]

On 18/01/06, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> sebb wrote:
> > According to
> >
> > http://vmgump.apache.org/gump/public/cocoon/wsrp4j/index.html
> >
> > "This project is not built by Gump."
> >
> > Presumably you mean "ws-wsrp4j" as in
> >
> Yes, sorry for that.
>
> > http://vmgump.apache.org/gump/public/ws-wsrp4j/ws-wsrp4j/index.html
> >
> > Clicking on the build  link gives
> >
> > http://vmgump.apache.org/gump/public/ws-wsrp4j/ws-wsrp4j/gump_work/build_ws-wsrp4j_ws-wsrp4j.html
> >
> > which shows that the pluto jar is included as
> >
> > /usr/local/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar
> >
> > The pluto module:
> >
> > http://vmgump.apache.org/gump/public/portals-pluto-1.0/index.html
> >
> > consists of 4 projects
> >
> > Perhaps you need to include a different output jar?
> >
> Yes, that's true - we need two of the projects from pluto: the
> portlet-api and portals-pluto-container. I think I added both to the
> ws-wsrp4j descriptor, but something must be wrong.

According to

http://vmgump.apache.org/gump/public/ws-wsrp4j/ws-wsrp4j/details.html

it only depends on the -api project currently

S
S.

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

Re: Help for WSRP4J

[sebb]

On 18/01/06, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
> Hi,
>
> the gump build of wsrp4j is failing for a long time now. I fail to see
> why :) From gump's error report, it seems that the pluto-1.0.1.jar is
> not in the build path. I think I added a reference to the pluto project
> some time ago, but this didn't fix the problem.
>
> Can anyone of the gump gurus help us?
>

I'm not a guru, but I have (ab)used gump for the JMeter project ...

==

According to

http://vmgump.apache.org/gump/public/cocoon/wsrp4j/index.html

"This project is not built by Gump."

Presumably you mean "ws-wsrp4j" as in

http://vmgump.apache.org/gump/public/ws-wsrp4j/ws-wsrp4j/index.html

Clicking on the build  link gives

http://vmgump.apache.org/gump/public/ws-wsrp4j/ws-wsrp4j/gump_work/build_ws-wsrp4j_ws-wsrp4j.html

which shows that the pluto jar is included as

/usr/local/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar

The pluto module:

http://vmgump.apache.org/gump/public/portals-pluto-1.0/index.html

consists of 4 projects

Perhaps you need to include a different output jar?

-
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 ?
>
> , 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:


  
   

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: 
> 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=349170&view=rev
> > Log:
> > Try adding home to fix work ...
> >
>
> I think that your biggest problem is that you have your  tags under
> your  tag (where they will be ignored :).  According to
> http://gump.apache.org/metadata/project.html, you need to move them to be
> under your  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



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  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  -
> >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: Where's GUMP repository gone?

[sebb]

http://svn.apache.org/repos/asf/gump/metadata

For example if using Eclipse, add the SVN location:
http://svn.apache.org/repos/asf/gump

and check out metadata

S.
On 12/08/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> In subversion (under metadata I think).
> 
> - Brett
> 
> On 8/12/05, Trustin Lee <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I've been keep receiving build failure messages from GUMP. Now I'm taking a
> > breath and fix the GUMP descriptors for some of my projects.
> >
> > But I was not able to locate GUMP descriptor repository. And I see broken
> > links in GUMP homepage.
> >
> > Can I know where's is the descriptor repository?
> >
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> >
> >
> 
> -
> 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
> 
> >
> >
> >
> >
> 
> looks complete, given that jakarta-site2 is
> 
> 
> 
> 
> 
> 
> 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: status of xalan breakage?

[sebb]

On Mon, 3 Jan 2005 12:45:15 -0500, Christine Li <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I investigated the failed gump build for xml-xalan before I went on
> vacation. From the error message, it looks like that there are some
> classpath setting issues. I have no objections to your temporary solution
> and I would like to collaborate to get this problem resolved as a
> developer for xalan.
> 
> I have no problem to build Xalan Head with both Sun JDK1.4.0_03 on
> Windows2000 (and the nightly ant build) as an independent project. Because
> of lack of information about the nightly gump build, I don't know what I
> can do at this moment.
> 
> Would you please let me know how I can reproduce the failed build?
> 1. version of JDK

See:
http://brutus.apache.org/gump/public/index.html

> 2. jar files on the bootclasspath
> 3. jar files and classes on classpath, etc.

See:
http://brutus.apache.org/gump/public/xml-xalan/xalan/details.html

> 4. Is there anyway that I can access archive of the gump build?
> 
> Any suggestions would be appreciated. Thanks,

Might be worth adding some debugging to the build.xml file - e.g.
directory listings etc. The classpath includes
/usr/local/gump/public/workspace/xml-xalan/java/build/classes - but
does that have the correct classes in it? And/or does the source file
for org.apache.xalan.transformer.TransformerImpl have the correct
method in it - perhaps a source code fetch went wrong.

It looks to me as if there may be a problem with the classes produced
by the xml.compile target, as this should be providing the missing
classes.

You could try adding a "clean" target to the gump build which deleted
all the build output. Or perhaps modify one or more of the files in
the xml.compile section to check that they are being processed - the
last few runs have not shown any compiles in that section.

Might be worth switching on some debug/trace (dunno how) to see what
ant and/or javac is processing.

HTH.

> 
> Original Message from Brett Porter <[EMAIL PROTECTED]>
> 
> >any objections to me doing this?
> >
> >1) create a xalan-failing project that uses xalan HEAD to build
> >2) make the xalan descriptor either package the last release, or build
> >from a known-good tag
> >3) when xalan-failing starts building again, switch back
> 
> 
> Christine Li
> XSLT Development
> IBM Toronto Lab
> Tel: (905)413-2601
> Email: [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]

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: 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: 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]