Re: svn commit: r1878298 - /gump/metadata/project/jsch.xml

[Mark Thomas]

On 30/05/2020 00:34, ma...@apache.org wrote:
> Author: markt
> Date: Fri May 29 23:34:14 2020
> New Revision: 1878298
> 
> URL: http://svn.apache.org/viewvc?rev=1878298=rev
> Log:
> Update jsch to 0.1.55

This might just fix the failing ant-dist build...

...assuming I haven't forgotten a version update somewhere, which, based
on past experience, is almost certain. jsch is only used by ant-dist so
if I have got it wrong it won't break anything that isn't already broken
and I'll (try and) fix it in ~12 hours after the next run.

Mark

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

Re: svn commit: r1829908 - /gump/metadata/project/eclipse.xml

[Stefan Bodewig]

On 2018-04-23, Mark Thomas wrote:

> On 23/04/18 18:00, bode...@apache.org wrote:

>> fix filename

> The original name was correct. Looks like I fat-fingered the on-disk
> name.

I see. I just spotted the mismatch while cleaning up the mess I created
around zstd-jni.

Stefan

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

Re: svn commit: r1829908 - /gump/metadata/project/eclipse.xml

[Mark Thomas]

On 23/04/18 18:00, bode...@apache.org wrote:
> Author: bodewig
> Date: Mon Apr 23 17:00:37 2018
> New Revision: 1829908
> 
> URL: http://svn.apache.org/viewvc?rev=1829908=rev
> Log:
> fix filename
> 
> Modified:
> gump/metadata/project/eclipse.xml
> 
> Modified: gump/metadata/project/eclipse.xml
> URL: 
> http://svn.apache.org/viewvc/gump/metadata/project/eclipse.xml?rev=1829908=1829907=1829908=diff
> ==
> --- gump/metadata/project/eclipse.xml (original)
> +++ gump/metadata/project/eclipse.xml Mon Apr 23 17:00:37 2018
> @@ -28,7 +28,7 @@
>  
>  
>  
> -
> +

The original name was correct. Looks like I fat-fingered the on-disk
name. I'll fix that.

Mark

-
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: svn commit: r1817993 - /gump/metadata/project/tomcat-trunk.xml

[Mark Thomas]

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.

> 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

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

[Stefan Bodewig]

On 2017-12-14, Konstantin Kolinko wrote:

> Configuration of Commons-Daemon at Gump was changed in r1817886 [2]

Yes, I did as the Ant build Gump used before has been removed.

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

I didn't see how it was built and am clueless enough when it comes to
mvn that I didn't think about assembly:single.

>  and
>   id="native-distro" />

+1

Stefan

-
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

[Konstantin Kolinko]

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.
The logs [1]:
[[[
trydownload:
  [get] Getting:
http://www.apache.org/dyn/closer.lua?action=download=/commons/daemon/source/commons-daemon-1.1.0-native-src.tar.gz
  [get] To:
/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs/download-1488937973.tmp
  [get] 
http://www.apache.org/dyn/closer.lua?action=download=/commons/daemon/source/commons-daemon-1.1.0-native-src.tar.gz
moved to 
http://mirror.novg.net/apache//commons/daemon/source/commons-daemon-1.1.0-native-src.tar.gz
]]]


Configuration of Commons-Daemon at Gump was changed in r1817886 [2]

Looking at pom.xml of commons-daemon, [3]
I see that it declares configuration for maven-assembly-plugin that
packs the src.tar.gz file,

but looking into Gump run logs for commons-daemon, I do not see
src.tar.gz file being built at all:
http://vmgump-vm3.apache.org/apache-commons/commons-daemon/gump_work/build_apache-commons_commons-daemon.html


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.

So this can be fixed by updating Gump configuration for commons-daemon to do
 and



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.



[1] 
http://vmgump-vm3.apache.org/tomcat-trunk/tomcat-trunk/gump_work/build_tomcat-trunk_tomcat-trunk.html
[2] http://svn.apache.org/viewvc?view=revision=1817886
[3] 
http://svn.apache.org/viewvc/commons/proper/daemon/trunk/pom.xml?revision=1816118=markup
[4] http://maven.apache.org/plugins/maven-assembly-plugin/

2017-12-13 12:43 GMT+03:00  <ma...@apache.org>:
> Author: markt
> Date: Wed Dec 13 09:43:40 2017
> New Revision: 1817993
>
> URL: http://svn.apache.org/viewvc?rev=1817993=rev
> Log:
> Remove unused (and in one case incorrect) property settings for Tomcat 9
>
> Modified:
> gump/metadata/project/tomcat-trunk.xml
>
> Modified: gump/metadata/project/tomcat-trunk.xml
> URL: 
> http://svn.apache.org/viewvc/gump/metadata/project/tomcat-trunk.xml?rev=1817993=1817992=1817993=diff
> ==
> --- gump/metadata/project/tomcat-trunk.xml (original)
> +++ gump/metadata/project/tomcat-trunk.xml Wed Dec 13 09:43:40 2017
> @@ -34,10 +34,6 @@
>
>id="commons-daemon" />
> -   -  id="native-distro" reference="outputpath" />
> -   -  id="native-distro" reference="outputpath" />
> id="junit" />
>
>  
>
>

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

Fwd: svn commit: r1808663 - /gump/metadata/project/commons-math-3.x.xml

[Dominik Stadler]

Hi,

thanks for cleaning up after me, I tried to run it locally and it seemed to
succeed, but some things around Gump are still a mystery to me, e.g. the
ant/maven/pom-magic...

Dominik.

-- Forwarded message --
From: <billbar...@apache.org>
Date: Mon, Sep 18, 2017 at 1:54 AM
Subject: svn commit: r1808663 - /gump/metadata/project/commons-math-3.x.xml
To: comm...@gump.apache.org


Author: billbarker
Date: Sun Sep 17 23:54:22 2017
New Revision: 1808663

URL: http://svn.apache.org/viewvc?rev=1808663=rev
Log:
Fix MVN coodinates and build order

Modified:
    gump/metadata/project/commons-math-3.x.xml

Modified: gump/metadata/project/commons-math-3.x.xml
URL: http://svn.apache.org/viewvc/gump/metadata/project/commons-
math-3.x.xml?rev=1808663=1808662=1808663=diff

==
--- gump/metadata/project/commons-math-3.x.xml (original)
+++ gump/metadata/project/commons-math-3.x.xml Sun Sep 17 23:54:22 2017
@@ -24,8 +24,8 @@

   

-  
-
+  
+
 
 
   
@@ -39,6 +39,7 @@
 

 
-
+
+
   
 

Re: svn commit: r1725406 - /gump/metadata/project/santuario.xml

[William Barker]

No problem. I've dealt with other projects that used this plugin

On Tuesday, January 19, 2016, Dominik Stadler <dominik.stad...@gmx.at>
wrote:

> Thanks for fixing! I was stumped by the error message and could not find
> out how to solve this.
>
> Dominik.
>
> On Tue, Jan 19, 2016 at 3:32 AM, <billbar...@apache.org <javascript:;>>
> wrote:
>
> > Author: billbarker
> > Date: Tue Jan 19 02:32:30 2016
> > New Revision: 1725406
> >
> > URL: http://svn.apache.org/viewvc?rev=1725406=rev
> > Log:
> > Allow it to use our jars, plus build order
> >
> > Modified:
> > gump/metadata/project/santuario.xml
> >
> > Modified: gump/metadata/project/santuario.xml
> > URL:
> >
> http://svn.apache.org/viewvc/gump/metadata/project/santuario.xml?rev=1725406=1725405=1725406=diff
> >
> >
> ======
> > --- gump/metadata/project/santuario.xml (original)
> > +++ gump/metadata/project/santuario.xml Tue Jan 19 02:32:30 2016
> > @@ -30,12 +30,15 @@
> >
> >  
> >  
> > +
> >  
> >
> >  
> >  
> >  
> >
> > +
> > +
> >  
> >  
> >  
> >
> >
> >
>

Re: svn commit: r1725406 - /gump/metadata/project/santuario.xml

[Dominik Stadler]

Thanks for fixing! I was stumped by the error message and could not find
out how to solve this.

Dominik.

On Tue, Jan 19, 2016 at 3:32 AM, <billbar...@apache.org> wrote:

> Author: billbarker
> Date: Tue Jan 19 02:32:30 2016
> New Revision: 1725406
>
> URL: http://svn.apache.org/viewvc?rev=1725406=rev
> Log:
> Allow it to use our jars, plus build order
>
> Modified:
> gump/metadata/project/santuario.xml
>
> Modified: gump/metadata/project/santuario.xml
> URL:
> http://svn.apache.org/viewvc/gump/metadata/project/santuario.xml?rev=1725406=1725405=1725406=diff
>
> ==
> --- gump/metadata/project/santuario.xml (original)
> +++ gump/metadata/project/santuario.xml Tue Jan 19 02:32:30 2016
> @@ -30,12 +30,15 @@
>
>  
>  
> +
>  
>
>  
>  
>  
>
> +
> +
>  
>  
>  
>
>
>

Re: svn commit: r1693677 - /gump/metadata/project/eclipse.xml

[Stefan Bodewig]

On 2015-08-01, billbar...@apache.org wrote:

 I can't remember if the cron job updates packages.

No.  This would require passwords of a PMC member to be stored or add a
technical user to svnauth of the private repo.  Neither sounds good to
me.

 If not somebody will have to 'svn update' it

Did just now.

Stefan

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

Re: svn commit: r1659978 - in /gump/metadata/project: tomcat-tc8.xml tomcat-trunk.xml

[William Barker]

On Feb 15, 2015 10:47 AM, rj...@apache.org wrote:

 Author: rjung
 Date: Sun Feb 15 18:47:16 2015
 New Revision: 1659978

 URL: http://svn.apache.org/r1659978
 Log:
 Partialy revert r1659974: outputpath is OK,
 don't need jarpath. The value in the logs seems
 OK. Investigating now, why tests are skipped.


The tests are skipped unless the openssl version exactly matches the
version Tomcat expects

 Modified:
 gump/metadata/project/tomcat-tc8.xml
 gump/metadata/project/tomcat-trunk.xml

 Modified: gump/metadata/project/tomcat-tc8.xml
 URL:
http://svn.apache.org/viewvc/gump/metadata/project/tomcat-tc8.xml?rev=1659978r1=1659977r2=1659978view=diff

==
 --- gump/metadata/project/tomcat-tc8.xml (original)
 +++ gump/metadata/project/tomcat-tc8.xml Sun Feb 15 18:47:16 2015
 @@ -104,7 +104,7 @@
property name=execute.test.nio value=false/
property name=execute.test.nio2 value=false/
property name=test.openssl.path
project=openssl-1.0.2-make-install
 -id=openssl reference=jarpath/
 +id=openssl reference=outputpath/
  /ant

 depend project=ant inherit=runtime /
 @@ -145,7 +145,7 @@
property name=execute.test.nio value=true/
property name=execute.test.nio2 value=false/
property name=test.openssl.path
project=openssl-1.0.2-make-install
 -id=openssl reference=jarpath/
 +id=openssl reference=outputpath/
  /ant

 depend project=ant inherit=runtime /
 @@ -186,7 +186,7 @@
property name=execute.test.nio value=false/
property name=execute.test.nio2 value=true/
property name=test.openssl.path
project=openssl-1.0.2-make-install
 -id=openssl reference=jarpath/
 +id=openssl reference=outputpath/
  /ant

 depend project=ant inherit=runtime /
 @@ -227,7 +227,7 @@
property name=execute.test.nio value=false/
property name=execute.test.nio2 value=false/
property name=test.openssl.path
project=openssl-1.0.2-make-install
 -id=openssl reference=jarpath/
 +id=openssl reference=outputpath/
property name=test.apr.loc project=tomcat-native-make-install
  reference=home/
  /ant

 Modified: gump/metadata/project/tomcat-trunk.xml
 URL:
http://svn.apache.org/viewvc/gump/metadata/project/tomcat-trunk.xml?rev=1659978r1=1659977r2=1659978view=diff

==
 --- gump/metadata/project/tomcat-trunk.xml (original)
 +++ gump/metadata/project/tomcat-trunk.xml Sun Feb 15 18:47:16 2015
 @@ -103,7 +103,7 @@
property name=execute.test.nio value=true/
property name=execute.test.nio2 value=false/
property name=test.openssl.path project=openssl-make-install
 -id=openssl reference=jarpath/
 +id=openssl reference=outputpath/
  /ant

 depend project=ant inherit=runtime /
 @@ -143,7 +143,7 @@
property name=execute.test.nio value=false/
property name=execute.test.nio2 value=true/
property name=test.openssl.path project=openssl-make-install
 -id=openssl reference=jarpath/
 +id=openssl reference=outputpath/
  /ant

 depend project=ant inherit=runtime /
 @@ -183,7 +183,7 @@
property name=execute.test.nio value=false/
property name=execute.test.nio2 value=false/
property name=test.openssl.path project=openssl-make-install
 -id=openssl reference=jarpath/
 +id=openssl reference=outputpath/
property name=test.apr.loc project=tomcat-native-make-install
  reference=home/
  /ant

Re: svn commit: r1659380 - /gump/metadata/project/openssl-1.0.2.xml

[David Crossley]

On Thu, Feb 12, 2015 at 07:56:01PM -, rj...@apache.org wrote:
 Author: rjung
 Date: Thu Feb 12 19:56:01 2015
 New Revision: 1659380
 
 URL: http://svn.apache.org/r1659380
 Log:
 Add OpenSSL 1.0.2 branch.

[snip]
 +  url href=http://www.openssl.org//
 +  description
 +OpenSSL Encryption Library (Branch 1.0.2)
 +  /description
 +
 +  git repository=github dir=/openssl/openssl 
 branch=OpenSSL_1_0_2-stable/

There is no attribute branch in metadata/dtd/project.dtd
so doing 'cd metadata; ./validate' fails.

Is this attribute used by gump? If so then we can add it.

-David

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

Re: svn commit: r1659380 - /gump/metadata/project/openssl-1.0.2.xml

[Konstantin Kolinko]

2015-02-13 1:02 GMT+03:00 David Crossley cross...@apache.org:
 On Thu, Feb 12, 2015 at 07:56:01PM -, rj...@apache.org wrote:
 Author: rjung
 Date: Thu Feb 12 19:56:01 2015
 New Revision: 1659380

 URL: http://svn.apache.org/r1659380
 Log:
 Add OpenSSL 1.0.2 branch.

 [snip]
 +  url href=http://www.openssl.org//
 +  description
 +OpenSSL Encryption Library (Branch 1.0.2)
 +  /description
 +
 +  git repository=github dir=/openssl/openssl 
 branch=OpenSSL_1_0_2-stable/

 There is no attribute branch in metadata/dtd/project.dtd
 so doing 'cd metadata; ./validate' fails.

 Is this attribute used by gump? If so then we can add it.

Added in r1659425.

Thank you.

Best regards,
Konstantin Kolinko

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

Re: Change metadata external at Gump live to use relative URL

[Konstantin Kolinko]

2015-02-11 8:14 GMT+03:00 Stefan Bodewig bode...@apache.org:
 On 2015-02-11, Konstantin Kolinko wrote:

 If I checkout the live directory, it has metadata directory as
 svn:external that is always checked out as http. As such, any changes
 to files in metadata cannot be committed as committing requires HTTPS.

 Fixed - oh, just saw your patch, looks better than my change.

 TBH I never thought about committing from inside the live directory.

My scenario was:
1) svn checkout /live  -- to look what it is and to follow up the changes
2) note that I have two copies of metadata (a standalone one that I
used before and the second one in live)
3) remove the standalone one to do not waste disk space on duplicates

4) make a change in live/metadata   (/project/tomcat-tc7.xml)
5) try to commit

 Apparently I do not have commit right to /live to fix it myself.

 I forgot to add Mark and yourself to the gump Unix group, done now.

Thank you!

Best regards,
Konstantin Kolinko

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

Re: svn commit: r1658850 - /gump/metadata/project/tomcat-tc7.xml

[Konstantin Kolinko]

2015-02-11 4:28 GMT+03:00 William Barker williamb...@gmail.com:
 On Feb 10, 2015 5:16 PM, kkoli...@apache.org wrote:

 Author: kkolinko
 Date: Wed Feb 11 01:16:15 2015
 New Revision: 1658850

 URL: http://svn.apache.org/r1658850
 Log:
 Configure APR connector tests for Tomcat 7.

 I never did this since Gump doesn't test AIO on Tomcat 7

 Modified:
 gump/metadata/project/tomcat-tc7.xml

 Modified: gump/metadata/project/tomcat-tc7.xml
 URL:
 http://svn.apache.org/viewvc/gump/metadata/project/tomcat-tc7.xml?rev=1658850r1=1658849r2=1658850view=diff

 ==
 --- gump/metadata/project/tomcat-tc7.xml (original)
 +++ gump/metadata/project/tomcat-tc7.xml Wed Feb 11 01:16:15 2015
 @@ -192,6 +192,52 @@
 nag to=d...@tomcat.apache.org
   from=Bill Barker lt;billbar...@apache.orggt; /
   /project
 + project name=tomcat-tc7.0.x-test-apr
 +   packageorg.apache.catalina/package
 +   ant target=test
 +  depend property=jdt.jar project=eclipse id=jdtcore /
 +  depend property=tomcat-dbcp.jar project=tomcat-tc7.0.x-dbcp
 id=tomcat-dbcp /
 +  property name=tomcat-dbcp-src.jar project=tomcat-tc7.0.x-dbcp
 +id=tomcat-dbcp-src reference=jarpath /
 +  depend property=commons-daemon.jar project=commons-daemon
 +  id=commons-daemon /
 +  property name=commons-daemon.native.src.tgz
 project=commons-daemon
 +  id=native-distro reference=outputpath /
 +  property name=tomcat-native.tar.gz project=commons-daemon
 +  id=native-distro reference=outputpath /
 +  depend property=junit.jar project=junit id=junit/
 +  depend property=hamcrest.jar project=hamcrest-java/
 +  property name=commons-pool.home project=commons-pool
 +path=. /
 +  property name=commons-dbcp.home project=commons-dbcp
 +path=. /
 +  property name=tomcat-dbcp.home project=tomcat-tc7.0.x-dbcp
 + reference=home /
 +  property name=examples.sources.skip value=true /
 +  property name=test.temp value=output/test-tmp-NIO /
 +  property name=test.reports value=output/logs-NIO /

 Did you mean APR here?

Fixed. Thank you!

I corrected the two report lines below when copy-pasting, but missed
the ones above.

 +  property name=test.accesslog value=true /
 +  property name=execute.test.apr value=true/
 +  property name=execute.test.bio value=false/
 +  property name=execute.test.nio value=false/
 +  property name=test.apr.loc project=tomcat-native-make-install
 +reference=home/
 +/ant
 +
 +   depend project=ant inherit=runtime /
 +   depend project=tomcat-tc7.0.x/
 +
 +   work nested=output/build/webapps/examples/WEB-INF/classes/
 +   work nested=output/testclasses /
 +
 +   license name=LICENSE /
 +
 +   report nested=output/logs-APR /
 +   report nested=output/test-tmp-APR/logs /


Best regards,
Konstantin Kolinko

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

Re: svn commit: r1658850 - /gump/metadata/project/tomcat-tc7.xml

[William Barker]

On Feb 10, 2015 5:16 PM, kkoli...@apache.org wrote:

 Author: kkolinko
 Date: Wed Feb 11 01:16:15 2015
 New Revision: 1658850

 URL: http://svn.apache.org/r1658850
 Log:
 Configure APR connector tests for Tomcat 7.

I never did this since Gump doesn't test AIO on Tomcat 7

 Modified:
 gump/metadata/project/tomcat-tc7.xml

 Modified: gump/metadata/project/tomcat-tc7.xml
 URL:
http://svn.apache.org/viewvc/gump/metadata/project/tomcat-tc7.xml?rev=1658850r1=1658849r2=1658850view=diff

==
 --- gump/metadata/project/tomcat-tc7.xml (original)
 +++ gump/metadata/project/tomcat-tc7.xml Wed Feb 11 01:16:15 2015
 @@ -192,6 +192,52 @@
 nag to=d...@tomcat.apache.org
   from=Bill Barker lt;billbar...@apache.orggt; /
   /project
 + project name=tomcat-tc7.0.x-test-apr
 +   packageorg.apache.catalina/package
 +   ant target=test
 +  depend property=jdt.jar project=eclipse id=jdtcore /
 +  depend property=tomcat-dbcp.jar project=tomcat-tc7.0.x-dbcp
id=tomcat-dbcp /
 +  property name=tomcat-dbcp-src.jar project=tomcat-tc7.0.x-dbcp
 +id=tomcat-dbcp-src reference=jarpath /
 +  depend property=commons-daemon.jar project=commons-daemon
 +  id=commons-daemon /
 +  property name=commons-daemon.native.src.tgz
project=commons-daemon
 +  id=native-distro reference=outputpath /
 +  property name=tomcat-native.tar.gz project=commons-daemon
 +  id=native-distro reference=outputpath /
 +  depend property=junit.jar project=junit id=junit/
 +  depend property=hamcrest.jar project=hamcrest-java/
 +  property name=commons-pool.home project=commons-pool
 +path=. /
 +  property name=commons-dbcp.home project=commons-dbcp
 +path=. /
 +  property name=tomcat-dbcp.home project=tomcat-tc7.0.x-dbcp
 + reference=home /
 +  property name=examples.sources.skip value=true /
 +  property name=test.temp value=output/test-tmp-NIO /
 +  property name=test.reports value=output/logs-NIO /

Did you mean APR here?

 +  property name=test.accesslog value=true /
 +  property name=execute.test.apr value=true/
 +  property name=execute.test.bio value=false/
 +  property name=execute.test.nio value=false/
 +  property name=test.apr.loc project=tomcat-native-make-install
 +reference=home/
 +/ant
 +
 +   depend project=ant inherit=runtime /
 +   depend project=tomcat-tc7.0.x/
 +
 +   work nested=output/build/webapps/examples/WEB-INF/classes/
 +   work nested=output/testclasses /
 +
 +   license name=LICENSE /
 +
 +   report nested=output/logs-APR /
 +   report nested=output/test-tmp-APR/logs /
 +
 +   nag to=d...@tomcat.apache.org
 + from=Bill Barker lt;billbar...@apache.orggt; /
 + /project
   project name=tomcat-tc7.0.x-validate
 packageorg.apache.catalina/package
 ant target=validate

Re: Change metadata external at Gump live to use relative URL

[Stefan Bodewig]

On 2015-02-11, Konstantin Kolinko wrote:

 If I checkout the live directory, it has metadata directory as
 svn:external that is always checked out as http. As such, any changes
 to files in metadata cannot be committed as committing requires HTTPS.

Fixed - oh, just saw your patch, looks better than my change.

TBH I never thought about committing from inside the live directory.

 Apparently I do not have commit right to /live to fix it myself.

I forgot to add Mark and yourself to the gump Unix group, done now.

Stefan

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

Change metadata external at Gump live to use relative URL

[Konstantin Kolinko]

Hi!

If I checkout the live directory, it has metadata directory as
svn:external that is always checked out as http. As such, any changes
to files in metadata cannot be committed as committing requires HTTPS.

Apparently I do not have commit right to /live to fix it myself.

The patch is
[[[
Use repository-root relative external syntax (supported since SVN 1.5),
so that metadata directory external can be downloaded by the same
protocol HTTPS protocol as its parent.

Index: .
===
--- .(revision 1658785)
+++ .(working copy)

Property changes on: .
___
Modified: svn:externals
## -1 +1 ##
-metadatahttp://svn.apache.org/repos/asf/gump/metadata
+^/gump/metadata metadata
]]]


Best regards,
Konstantin Kolinko

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

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

[Stefan Bodewig]

On 2014-06-20, billbar...@apache.org wrote:

 restore repo that works

ah, sorry, applied the ediff-chunk in Emacs to the wrong file when
fixing the testbase.  Thanks for cleaning up.

Stefan

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

Checkstyle (svn commit: r1552445 - /gump/metadata/project/xml-fop.xml)

[David Crossley]

Hi, i see that Tomcat also use Checkstyle.

If you continue to have trouble, then perhaps look
at how they do it.

cd $SVN/gump/metadata/project/
grep checkstyle *.xml

Hope that helps.

-David

vhenneb...@apache.org wrote:
 Author: vhennebert
 Date: Thu Dec 19 22:24:55 2013
 New Revision: 1552445
 
 URL: http://svn.apache.org/r1552445
 Log:
 Second attempt to fix Checkstyle dependencies by adding them directly to the 
 FOP descriptor
 
 Modified:
 gump/metadata/project/xml-fop.xml
 
 Modified: gump/metadata/project/xml-fop.xml
 URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/xml-fop.xml?rev=1552445r1=1552444r2=1552445view=diff
 ==
 --- gump/metadata/project/xml-fop.xml (original)
 +++ gump/metadata/project/xml-fop.xml Thu Dec 19 22:24:55 2013
 @@ -69,7 +69,12 @@
sysproperty name=ant.build.clonevm value=true/
property name=checkstyle.location project=checkstyle 
 reference=jarpath id=checkstyle/
  /ant
 -depend project=checkstyle inherit=runtime/
 +depend project=checkstyle/
 +depend project=commons-beanutils/
 +depend project=commons-cli/
 +depend project=commons-exec/
 +depend project=commons-validator/
 +depend project=google-guava /
  depend project=xml-fop inherit=all/
  depend project=fop-hyph/
  depend project=junit/
 
 

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

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

[David Crossley]

 Author: billbarker
 Date: Fri Aug  2 05:16:04 2013
 New Revision: 1509547
 
 URL: http://svn.apache.org/r1509547
 Log:
 dbcp build is now integrated into the regular tomcat build
 
 Modified:
 gump/metadata/project/tomcat-trunk.xml
 
 Modified: gump/metadata/project/tomcat-trunk.xml
 URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/tomcat-trunk.xml?rev=1509547r1=1509546r2=1509547view=diff
 ==
 --- gump/metadata/project/tomcat-trunk.xml (original)
 +++ gump/metadata/project/tomcat-trunk.xml Fri Aug  2 05:16:04 2013
 @@ -27,6 +27,7 @@
  
svn repository=asf dir=tomcat/trunk/
  
 +  mkdir dir=tomcat-deps /

The metadata validation system does not like that mkdir
being outside of a project.

Do 'cd metadata; ./validate'

Is it just a remnant of the stuff that was removed?

-David

project name=tomcat-trunk
  packageorg.apache.catalina/package
  ant
 @@ -42,12 +43,12 @@
property name=tomcat-native.tar.gz project=commons-daemon
id=native-distro reference=outputpath /
property name=junit.jar project=junit reference=jarpath 
 id=junit /
 -  property name=commons-pool.home project=commons-pool
 - path=. /
 -  property name=commons-dbcp.home project=commons-dbcp
 - path=. /
 -  property name=tomcat-dbcp.home project=tomcat-trunk-dbcp

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

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

[Stefan Bodewig]

On 2013-08-12, David Crossley wrote:

+  mkdir dir=tomcat-deps /

 The metadata validation system does not like that mkdir
 being outside of a project.

I've seen that as well, when I looked through the remaining descriptors,
I don't even think it does anything.  I've moved it.

Stefan

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

Re: svn commit: r1303274 - /gump/metadata/repository/google-guava.xml

[Bill Barker]

-Original Message- 
From: Stefan Bodewig

Sent: Tuesday, March 20, 2012 10:28 PM
To: general@gump.apache.org
Subject: Re: svn commit: r1303274 - 
/gump/metadata/repository/google-guava.xml



On 2012-03-21, Bill Barker wrote:


It seems that I've forgotten my opie password on vmgump.


I've changed your password, there is a file in your home dir holding the
new one.  You can use opiepasswd to change it again.


Ha ha, very funny :).  I actually can speak German.


Could someone clear the google-guava cvs repository?


That's not necessary, gump will detect the new scm definition doesn't
match what is on the disk and remove the old directory by itself.

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: r1303274 - /gump/metadata/repository/google-guava.xml

[Bill Barker]

It seems that I've forgotten my opie password on vmgump. Could someone clear 
the google-guava cvs repository?  I doubt it will go down well with infra, 
but changing the umask for gump to include group-writable and adding me to 
the gump group would allow me to do this sort of routine cleanup without 
having access to sudo.


-Original Message- 
From: billbar...@apache.org

Sent: Tuesday, March 20, 2012 9:11 PM
To: comm...@gump.apache.org
Subject: svn commit: r1303274 - /gump/metadata/repository/google-guava.xml

Author: billbarker
Date: Wed Mar 21 04:11:40 2012
New Revision: 1303274

URL: http://svn.apache.org/viewvc?rev=1303274view=rev
Log:
It seems that guava has moved to git, but still not sure this will work

Modified:
   gump/metadata/repository/google-guava.xml

Modified: gump/metadata/repository/google-guava.xml
URL: 
http://svn.apache.org/viewvc/gump/metadata/repository/google-guava.xml?rev=1303274r1=1303273r2=1303274view=diff

==
--- gump/metadata/repository/google-guava.xml (original)
+++ gump/metadata/repository/google-guava.xml Wed Mar 21 04:11:40 2012
@@ -16,13 +16,13 @@
  limitations under the License.
--

-repository name=google-guava type=svn
+repository name=google-guava type=git
  titleGoogle Guava/title
  home-pagehttp://code.google.com/p/guava-libraries//home-page

  webhttp://code.google.com/p/guava-libraries/source/browse/trunk/web

-  urlhttp://guava-libraries.googlecode.com/svn/trunk//url
+  urlhttps://code.google.com/p/guava-libraries//url

  redistributable/
/repository


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

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

[Konstantin Kolinko (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/GUMP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211566#comment-13211566
 ] 

Konstantin Kolinko commented on GUMP-153:
-

As far as I enjoy reviewing Gump results, all metadata links do work. So this 
7-year old issue is actually already resolved.

 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. 

With current svn server version it is possible to do. It now supports URL 
syntax with revision numbers, e.g.:
http://svn.apache.org/repos/asf/gump/metadata/project/lucene-java.xml?p=1234567

I am using syntax with a peg revision above (operative revision defaults to the 
peg one).
The authoritative reference can be found in the Subversion book, see URL 
syntax section in httpd server chapter: 
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra

 Gump Metadata: links no longer work
 ---

 Key: GUMP-153
 URL: https://issues.apache.org/jira/browse/GUMP-153
 Project: Gump
  Issue 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, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

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

[Konstantin Kolinko (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/GUMP-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211583#comment-13211583
 ] 

Konstantin Kolinko commented on GUMP-161:
-

See my comment to GUMP-153

 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.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

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

[Stefan Bodewig]

On 2011-08-10, t...@apache.org wrote:

 Attempt to move JCS build to Maven2. Tests will be skipped for now as
 some of them still fail - already under investigation. Please verify
 my changes.

Looks OK except for some smaller nits I've already changed, see below.

You should be able to turn all depend into option elements when
using mvn.  I'll keep an eye on the next builds to ensure mvn doesn't
start to download any other dependencies currently not listed and add
options for those as well so we get the build order right.

mvn2 basedir=exec goal=package

You meant basedir=jcs, right?

 -  project name=jcs groupId=jcs
 -depend project=jakarta-turbine-jcs/
 -jar name=jcs/target/jcs-@@DATE@@.jar id=jcs/
 -license name=LICENSE.txt/
 -  /project

This is an alias currently used by James.  I'm not really sure it is
still needed, but if you remove it Gump's project graph has a hole.
For now I've added it back.

Stefan

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

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

[sebb]

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

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

Sorry about that - not sure how that happened.

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


 Modified:
    gump/metadata/profile/gump.xml

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

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

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

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

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




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

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

[Stefan Bodewig]

On 2011-04-12, sebb wrote:

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

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

 Sorry about that - not sure how that happened.

No problem.

 I would have thought that SVN should have complained that my working
 copy was out of date.

I've been thinking the same so far.

Stefan

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

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

[sebb]

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

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

 I know 8-)

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

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

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

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

 I do not have CPU cycles to develop that

 Me neither, sorry.

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

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

But I don't currently have that knowledge.

 Stefan

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



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

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

[Antoine Levy-Lambert]

Hello Stefan,

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


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 ?


I do not have CPU cycles to develop that but my guess is that it would help.

Regards,

Antoine


On 3/1/2011 11:54 AM, bode...@apache.org wrote:

Author: bodewig
Date: Tue Mar  1 16:54:44 2011
New Revision: 1075910

URL: http://svn.apache.org/viewvc?rev=1075910view=rev
Log:
more refactorings in directory-shared

Modified:
 gump/metadata/project/directory-apacheds.xml
 gump/metadata/project/directory-shared.xml





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

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

[Stefan Bodewig]

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.

Stefan

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

Re: svn commit: r1068427 - /gump/metadata/project/xml-fop.xml

[Stefan Bodewig]

On 2011-02-08, jerem...@apache.org wrote:

 Using nested QDox since Gump provides only an old version (1.6.3).

I've upgraded qdox to 1.12.

Stefan

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

Re: svn commit: r1057143 - /gump/metadata/project/santuario.xml

[Stefan Bodewig]

Hi Colm,

On 2011-01-10, cohei...@apache.org wrote:

 URL: http://svn.apache.org/viewvc?rev=1057143view=rev
 Log: (empty)

 Modified:
 gump/metadata/project/santuario.xml

 Modified: gump/metadata/project/santuario.xml
 URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/santuario.xml?rev=1057143r1=1057142r2=1057143view=diff
 ==
 --- gump/metadata/project/santuario.xml (original)
 +++ gump/metadata/project/santuario.xml Mon Jan 10 10:25:37 2011
 @@ -35,7 +35,7 @@
property name=product.version value=@@DATE@@/
  /ant

 -depend project=ant inherit=runtime/
 +!--depend project=ant inherit=runtime/--

I'm not sure what you are trying to do here, but if the project builds
using Ant (which the descriptor says) then it must depend on Ant.  I've
reverted this.

The build failures of the past few days occured because the descriptor
specifically demanded JUnit 3.x rather than 4.x and so the org.junit
package has not been available.  This has been fixed a few minutes
before you changed the descriptor yourself.

Stefan

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

Re: Builds on adam (Re: svn commit: r1036884 - /gump/metadata/testbase/commons-lang-3.x.xml)

[Stefan Bodewig]

On 2010-11-19, Stefan Bodewig wrote:

 On 2010-11-19, bode...@apache.org wrote:

 Try to push headless configuration into Maven build

 Unfortunately this didn't help either since java.awt.headless never
 reaches the tests

I've just checked in another change that makes Surefire pass the same
parameter to the forked java VM and now commons-lang3 builds on adam.
The only failures remaining are the args4j errors that would need Sander
to run the maven 1.x build manually once and NUnit which is known to
cause problems.  Nothing that would prevent us from running a full Gump
set IMHO.

Still the same headless issue will appear for more than just the
commons-lang3 build then and will need to get addressed individually.

 I'll raise this on the commons dev list.

Did so and got some supporting comments that may lead to a solution for
all Apache Commons projects, at least.

Stefan

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

Builds on adam (Re: svn commit: r1036884 - /gump/metadata/testbase/commons-lang-3.x.xml)

[Stefan Bodewig]

On 2010-11-19, bode...@apache.org wrote:

 Try to push headless configuration into Maven build

Unfortunately this didn't help either since java.awt.headless never
reaches the tests - likely because the tests run in a forked VM.  The
commons-lang3 build remains broken.

I'll raise this on the commons dev list.

Stefan

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

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

[Sebb (JIRA)]

Apache Gump Metadata does not show actual version used
--

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


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

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

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


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

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

[sebb]

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

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

Sorry about that - missed the embedded comment.


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

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




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

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

[sebb]

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

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

 Modified:
    gump/metadata/project/checkstyle.xml

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

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

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

          id=checkstyle/

     license name=LICENSE/




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

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

[Stefan Bodewig]

On 2010-09-27, sebb wrote:

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

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

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

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

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

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

Stefan

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

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

[Maarten Coene]

If the pattern has to be a regular expression, it should be:
jar name=target/checkstyle-.*[0-9T].jar /

Maarten

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

 From: Stefan Bodewig bode...@apache.org
 Subject: Re: svn commit: r1001631 - /gump/metadata/project/checkstyle.xml
 To: general@gump.apache.org
 Date: Monday, September 27, 2010, 12:48 PM
 On 2010-09-27, sebb wrote:
 
  On 27 September 2010 10:07,  bode...@apache.org
 wrote:
 
  I don't know why wildcards sometimes don't seem to
 work
 
  -    jar
 name=target/checkstyle-*[0-9T].jar
  +    jar
 name=target/checkstyle-5.3-SNAPSHOT.jar
 
  Perhaps they don't work because of the -SNAPSHOT
 suffix?
 
 No, that works in several other projects.  And the
 wildcard should still
 match anyway (that's why there is a T in the group).
 
 My best guess currently is - and confirming/fixing it is on
 my TODO
 list, somewhere - that under certain circumstances the
 wildcards get
 expanded before the jar has actually been built.
 
 Stefan
 
 -
 To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
 For additional commands, e-mail: general-h...@gump.apache.org
 
 




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

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

[sebb]

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

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

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

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

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

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


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

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

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

 Stefan

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



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

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

[sebb]

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

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

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

 Maarten

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

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

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

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

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

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

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

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

 Stefan

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






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



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

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

[Stefan Bodewig]

On 2010-09-27, sebb wrote:

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

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

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

 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?

You get an error but with a different error message.

See the expand_outputs method in
http://svn.apache.org/repos/asf/gump/trunk/python/gump/core/model/project.py

If the pattern doesn't match anything, the error code is set later in a
different location and you only see the debug statement.  If it matches
more than one file the error message would tell you how many it has
matched.

Hmm, now that I see the code, I think I spot the problem, the last line
should be indented one level deeper so it only sets the outputs_expanded
property to true if outputs have actually been expanded.  I'll try that
in my sandbox and commit the change to trunk this evening.  It doesn't
explain why the method sometimes is invoked with self.built being false,
but it should delay the expansion.

Stefan

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

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

[Niall Pemberton]

On Tue, Sep 21, 2010 at 8:28 AM,  bode...@apache.org wrote:
 Author: bodewig
 Date: Tue Sep 21 07:28:24 2010
 New Revision: 999257

 URL: http://svn.apache.org/viewvc?rev=999257view=rev
 Log:
 try publishing beanutils' POM as beanutils-core POM, not sure it will work

It should be OK. It will have an additional (unnecessary) dependency
on Commons Collections - but that shouldn't cause any problems.

Niall

 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=999257r1=999256r2=999257view=diff
 ==
 --- gump/metadata/project/commons-proper.xml (original)
 +++ gump/metadata/project/commons-proper.xml Tue Sep 21 07:28:24 2010
 @@ -78,6 +78,7 @@
   !-- alias to make mvn2 happy --
   project name=commons-beanutils-core groupId=commons-beanutils
     depend project=commons-beanutils/
 +    pom name=beanutils/pom.xml/
     jar name=beanutils/dist/commons-beanutils-@@DATE@@.jar 
 id=commons-beanutils-core/
   /project





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

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

[Niall Pemberton]

On Tue, Sep 21, 2010 at 10:30 AM, Stefan Bodewig bode...@apache.org wrote:
 On 2010-09-21, Niall Pemberton wrote:

 On Tue, Sep 21, 2010 at 8:28 AM,  bode...@apache.org wrote:
 Author: bodewig
 Date: Tue Sep 21 07:28:24 2010
 New Revision: 999257

 URL: http://svn.apache.org/viewvc?rev=999257view=rev
 Log:
 try publishing beanutils' POM as beanutils-core POM, not sure it will work

 It should be OK. It will have an additional (unnecessary) dependency
 on Commons Collections - but that shouldn't cause any problems.

 The reason I added it was

 http://vmgump.apache.org/gump/public/checkstyle/checkstyle/gump_work/build_checkstyle_checkstyle.html

 Which looks like a project using (a released version of) beanutils but
 not depending on commons-collections, like we've seen for
 digester-test.  checkstyle doesn't depend on beanutils but only on
 beantils-core but since we publish the normal beanutils jar as
 beanutils-core in Gump it may be that this dependency on
 commons-collections only exists inside Gump.

BeanUtils used to have a copy of the Collections FastHashMap (and 4
other collections classes). With those BeanUtils core had no
dependency on Commons Collections. There are other clases in BeanUtils
which did require Commons Collections, but they were excluded from the
Core jar. This was a mess so I removed the copied classes and dumped
the BeanUtils core jar. So now there is only one BeanUtils jar and
anything that depends on it requires Commons Collections:

https://issues.apache.org/jira/browse/BEANUTILS-379

So effectively the core dependency has disappeared. Not sure how
gump should/can handle that. Perhaps a *packaged* version of beanutils
core. Or as I guess you're trying to do - feed in BeanUtils as core -
but those projects that depend on it will now requires Commons
Collections.

 The not sure it will work part is more about the fact that the POM
 will specify a different artifactId than mvn asks for and I don't know
 whether mvn will ignore this or reject the POM or explode or whatever.

OK, me neither - I guess we'll see after the next run.

Niall

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

[Stefan Bodewig]

On 2010-09-21, Niall Pemberton wrote:

 So effectively the core dependency has disappeared. Not sure how
 gump should/can handle that. Perhaps a *packaged* version of beanutils
 core. Or as I guess you're trying to do - feed in BeanUtils as core -
 but those projects that depend on it will now requires Commons
 Collections.

Yes, this is what I'm trying.  The projects that use beanutils-core
would transitively depend on commons-collections then.

An alternative is a Gump specific POM - we already have two for Xalan
and Ant 1.6.x - that adds the dependency.  In beanutils-core case it
could even be a relocation POM that points to commons-beanutils.

 On Tue, Sep 21, 2010 at 10:30 AM, Stefan Bodewig bode...@apache.org wrote:

 The not sure it will work part is more about the fact that the POM
 will specify a different artifactId than mvn asks for and I don't know
 whether mvn will ignore this or reject the POM or explode or whatever.

 OK, me neither - I guess we'll see after the next run.

Yes.

Stefan

-
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

[Stefan Bodewig]

On 2010-09-14, s...@apache.org wrote:

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

Uhm, no.  I've reverted that part.

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

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

Stefan

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

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

[sebb]

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

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

 Uhm, no.  I've reverted that part.

Sorry ...

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

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

... thanks for the explanation.

 Stefan

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



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

Re: svn commit: r960141 - /gump/metadata/project/forrest.xml

[Stefan Bodewig]

On 2010-07-03, David Crossley wrote:

 Stefan Bodewig wrote:
 David Crossley wrote:

 Use jing from our packaged supporting products until we get
 jing-trang happening with gump.

 Can you provide the details to try and build it inside Gump?

 I have not yet tried to investigate ...

 http://jing-trang.googlecode.com/svn/trunk/readme.txt

Since Forrest is the only project using it right now, please add it when
you feel you are ready for it - and yell if you need help.

Stefan

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

Re: svn commit: r960141 - /gump/metadata/project/forrest.xml

[Stefan Bodewig]

On 2010-07-03, cross...@apache.org wrote:

 Use jing from our packaged supporting products until we get
 jing-trang happening with gump.

Can you provide the details to try and build it inside Gump?

Stefan

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

Re: svn commit: r960141 - /gump/metadata/project/forrest.xml

[David Crossley]

Stefan Bodewig wrote:
 David Crossley wrote:
 
  Use jing from our packaged supporting products until we get
  jing-trang happening with gump.
 
 Can you provide the details to try and build it inside Gump?

I have not yet tried to investigate ...

http://jing-trang.googlecode.com/svn/trunk/readme.txt

-David

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

Re: svn commit: r953937 - /gump/metadata/project/excalibur.xml

[Stefan Bodewig]

On 2010-06-12, Bill Barker wrote:

 it looked like we were just getting a lot of server errors here.  I
 was going to give another cycle before diving in.

I see.  Right now we again seem to be in network trouble so you may just
have been right with waiting.

Stefan

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

Re: svn commit: r953937 - /gump/metadata/project/excalibur.xml

[Bill Barker]

--
From: bode...@apache.org
Sent: Friday, June 11, 2010 10:18 PM
To: comm...@gump.apache.org
Subject: svn commit: r953937 - /gump/metadata/project/excalibur.xml


Author: bodewig
Date: Sat Jun 12 05:18:53 2010
New Revision: 953937

URL: http://svn.apache.org/viewvc?rev=953937view=rev
Log:
install excalibur-event-api POM.  We need to find a better way for this 
kind of stuff.  Why isn't the install goal pushing the POM into the local 
repository?




This can't hurt, but it looked like we were just getting a lot of server 
errors here.  I was going to give another cycle before diving in.




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

Re: svn commit: r949452 - in /gump/metadata: profile/gump.xml project/logging-log4j-2.xml

[Stefan Bodewig]

On 2010-05-30, carn...@apache.org wrote:

 Added:
 gump/metadata/project/logging-log4j-2.xml
   - copied unchanged from r949450, 
 gump/metadata/project/logging-log4j-12.xml

this is likely not what you have intended (the unchanged bit).  I'll
rename the module and projects for a start, but the svn URL is probably
wrong as well.

Stefan

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

Re: svn commit: r949452 - in /gump/metadata: profile/gump.xml project/logging-log4j-2.xml

[Curt Arnold]

On May 31, 2010, at 1:31 AM, Stefan Bodewig wrote:

 On 2010-05-30, carn...@apache.org wrote:
 
 Added:
gump/metadata/project/logging-log4j-2.xml
  - copied unchanged from r949450, 
 gump/metadata/project/logging-log4j-12.xml
 
 this is likely not what you have intended (the unchanged bit).  I'll
 rename the module and projects for a start, but the svn URL is probably
 wrong as well.
 
 Stefan
 

Sorry about that.  The changes that I wanted were lingering in an unsaved 
window on my editor.

Here are the pertinent facts,

 svn repository=asf dir=logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/

Maven multi-project pom.xml in root.

Some unit tests depend on oro and junit3.

Code is highly experimental.

Don't care about artifacts at the moment and nobody should depend on use 
anytime soon, maybe I should have started with continuum.  Gump was my reflex 
and everything else for logging was already there.  If you agree or have 
another suggestion, then we can revert my earlier changes.

There is a stray F in the current pom just inside the top element.


p.s.: I know I'm overdue at looking at the log4cxx failures.


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

Re: svn commit: r949452 - in /gump/metadata: profile/gump.xml project/logging-log4j-2.xml

[Stefan Bodewig]

On 2010-05-31, Curt Arnold wrote:

 On May 31, 2010, at 1:31 AM, Stefan Bodewig wrote:

 this is likely not what you have intended (the unchanged bit).

 Sorry about that.  The changes that I wanted were lingering in an
 unsaved window on my editor.

Been there, done that.

 Here are the pertinent facts,

  svn repository=asf dir=logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/

 Maven multi-project pom.xml in root.

 Some unit tests depend on oro and junit3.

If you want to, please go ahead and make the changes yourself.
Otherwise I can do so later today.  Please add optional dependencies on
commons-collections and velocity-engine as well since mvn is going to
download those for some plugins.

 Don't care about artifacts at the moment

Just remove the jar-Elements.

 p.s.: I know I'm overdue at looking at the log4cxx failures.

The failures are due to changes in APR land.  apt-util has been merged
with apr and apr itself has changed the directory layout of its
installation.

Stefan

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

Re: svn commit: r941172 - in /gump/metadata/project: apache-httpd.xml logging-log4cxx.xml

[Bill Barker]

--
From: bode...@apache.org
Sent: Wednesday, May 05, 2010 12:05 AM
To: comm...@gump.apache.org
Subject: svn commit: r941172 - in /gump/metadata/project: apache-httpd.xml 
logging-log4cxx.xml



Author: bodewig
Date: Wed May  5 07:05:50 2010
New Revision: 941172

URL: http://svn.apache.org/viewvc?rev=941172view=rev
Log:
what would break if we removed the old apr-util branch?



Urm, pretty much every thing.  The problem is that current apr-util/trunk 
won't build with apr/trunk.  IMHO this is a problem for the Apache-Apr 
community to work out.  We could provide a legacy apr build to fix this in 
the meantime, but not really the Gump Way.



Modified:
   gump/metadata/project/apache-httpd.xml
   gump/metadata/project/logging-log4cxx.xml

Modified: gump/metadata/project/apache-httpd.xml
URL: 
http://svn.apache.org/viewvc/gump/metadata/project/apache-httpd.xml?rev=941172r1=941171r2=941172view=diff

==
--- gump/metadata/project/apache-httpd.xml (original)
+++ gump/metadata/project/apache-httpd.xml Wed May  5 07:05:50 2010
@@ -29,11 +29,11 @@
script name=buildconf
  arg name=--with-apr project=apr-make-install
reference=home/
-  arg name=--with-apr-util project=apr-util-make-install
-reference=home/
+  !--arg name=--with-apr-util project=apr-util-make-install
+reference=home/--
/script
depend project=apr-make-install/
-depend project=apr-util-make-install/
+!--depend project=apr-util-make-install/--
  /project

  project name=apache-httpd-configure
@@ -41,8 +41,8 @@
  arg name=--prefix path=dest-@@DATE@@/
  arg name=--with-apr project=apr-configure
reference=home/
-  arg name=--with-apr-util project=apr-util-configure
-reference=home/
+  !--arg name=--with-apr-util project=apr-util-configure
+reference=home/--
  arg name=--with-pcre project=pcre-configure
reference=home/
/configure

Modified: gump/metadata/project/logging-log4cxx.xml
URL: 
http://svn.apache.org/viewvc/gump/metadata/project/logging-log4cxx.xml?rev=941172r1=941171r2=941172view=diff

==
--- gump/metadata/project/logging-log4cxx.xml (original)
+++ gump/metadata/project/logging-log4cxx.xml Wed May  5 07:05:50 2010
@@ -31,8 +31,8 @@
  !-- property name=version value=@@DATE@@/ --
  property name=apr.dir project=apr-configure
reference=home/
-  property name=aprutil.dir project=apr-util-configure
-reference=home/
+  !--property name=aprutil.dir project=apr-util-configure
+reference=home/--
  property name=find value=false/
/ant

@@ -42,7 +42,7 @@
depend project=ant-contrib-cpptasks/
depend project=ant-contrib inherit=runtime/
depend project=apr-make-install/
-depend project=apr-util-make-install/
+!--depend project=apr-util-make-install/--

nag to=carn...@apache.org
 from=Gump Integration Build lt;carn...@apache.orggt;/
@@ -55,8 +55,8 @@
  !-- property name=version value=@@DATE@@/ --
  property name=apr.dir project=apr-configure
reference=home/
-  property name=aprutil.dir project=apr-util-configure
-reference=home/
+  !--property name=aprutil.dir project=apr-util-configure
+reference=home/--
  property name=find value=false/
/ant

@@ -66,7 +66,7 @@
depend project=ant-contrib-cpptasks/
depend project=ant-contrib inherit=runtime/
depend project=apr-make-install/
-depend project=apr-util-make-install/
+!--depend project=apr-util-make-install/--

nag to=carn...@apache.org
 from=Gump Integration Build lt;carn...@apache.orggt;/
@@ -79,8 +79,8 @@
  !-- property name=version value=@@DATE@@/ --
  property name=apr.dir project=apr-configure
reference=home/
-  property name=aprutil.dir project=apr-util-configure
-reference=home/
+  !--property name=aprutil.dir project=apr-util-configure
+reference=home/--
  property name=lib.type value=static/
  property name=find value=false/
/ant
@@ -91,7 +91,7 @@
depend project=ant-contrib-cpptasks/
depend project=ant-contrib inherit=runtime/
depend project=apr-make-install/
-depend project=apr-util-make-install/
+!--depend project=apr-util-make-install/--

nag to=carn...@apache.org
 from=Gump Integration Build lt;carn...@apache.orggt;/
@@ -106,11 +106,11 @@
configure
  arg name=--prefix path=dest-@@DATE@@/
  arg name=--with-apr project=apr-make-install reference=home/
-  arg name=--with-apr-util project=apr-util-make-install 
reference=home/
+  !--arg name=--with-apr-util project=apr-util-make-install 
reference=home/--

/configure
depend project=logging-log4cxx-autogen/
depend project=apr-make-install/
-depend project=apr-util-make-install

Re: svn commit: r941172 - in /gump/metadata/project: apache-httpd.xml logging-log4cxx.xml

[Stefan Bodewig]

On 2010-05-05, Bill Barker billwbar...@verizon.net wrote:

 URL: http://svn.apache.org/viewvc?rev=941172view=rev
 Log:
 what would break if we removed the old apr-util branch?

 Urm, pretty much every thing.  The problem is that current
 apr-util/trunk won't build with apr/trunk.

My understanding is that APR-util has been merged into APR - there is no
apr-util trunk at all.

 We could provide a legacy apr build to fix this in the meantime, but
 not really the Gump Way.

This is what I'm trying to find out.  Do the httpd and log4cpp builds
assume apr-util was a separate build or not?  If they still do, we'll
need a packaged version of apr-util IMHO.

Stefan

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

Re: svn commit: r941556 - /gump/metadata/project/apache-httpd.xml

[Stefan Bodewig]

On 2010-05-06, billbar...@apache.org wrote:

 work around broken xml parser

Thanks.  My fault, not the XML parser's.  The literal -- is illegal
inside XML comments.

Stefan

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

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

[sebb]

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

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

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

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

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

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




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

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

[Stefan Bodewig]

On 2010-04-16, sebb seb...@gmail.com wrote:

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

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

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

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

Well, one is dead anyway (OJB doesn't build on Java6 and hasn't seen a
commit in more than two years) and the other one is heading towards the
Attic, it wouldn't have done much harm.

Once we start removing Slide and Taglibs things will become more
difficult since there are quite a few dependencies on slide-webdavlib
(will need an installed package for the Ant and Maven 1 based builds)
and taglibs-standard (can be replaced by something in tomcat svn?).

Stefan

-
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

[Stefan Bodewig]

On 2010-04-16, Stefan Bodewig bode...@apache.org wrote:

 and taglibs-standard (can be replaced by something in tomcat svn?).

It is already pulled from tomcat, I'll rename the descriptor and project
to make this explicit.

Stefan

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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Antoine Levy Lambert]

Hi,

Is it the same like installing the snapshot artifacts in the local 
~/.m2 cache ?


I am looking at some of the stuff which is lying on my hard drive :

/Users/antoine/.m2/repository/org/apache/commons/commons-openpgp/1.0-SNAPSHOT
antoine-levy-lamberts-macbook:1.0-SNAPSHOT antoine$ ls
commons-openpgp-1.0-SNAPSHOT.jarmaven-metadata-local.xml
commons-openpgp-1.0-SNAPSHOT.pom


Regards,

Antoine

Stefan Bodewig wrote:

On 2010-03-16, Bill Barker billwbar...@verizon.net wrote:

  

I was thinking of adding a localRepository=name to the mvn /
builder that allows projects to share a local repo when they can't be
trusted to use the central repo.  These would be cleaned when Gump
finishes (or maybe on startup).



Sounds like a good idea.  It would probably solve the castor-xml case as
well when castor-xml can share the local repository with castor-core.

Stefan

  



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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Stefan Bodewig]

On 2010-03-19, Antoine Levy Lambert anto...@gmx.de wrote:

 On 2010-03-16, Bill Barker billwbar...@verizon.net wrote:

 I was thinking of adding a localRepository=name to the mvn /
 builder that allows projects to share a local repo when they can't be
 trusted to use the central repo.  These would be cleaned when Gump
 finishes (or maybe on startup).

 Is it the same like installing the snapshot artifacts in the local
 ~/.m2 cache ?

Yes, I think so.  Only that we'd be using a directory other than ~/.m2
that would get purged after the Gump run has finished.

Stefan

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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Bill Barker]

--
From: Stefan Bodewig bode...@apache.org
Sent: Friday, March 19, 2010 6:39 AM
To: general@gump.apache.org
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-19, Antoine Levy Lambert anto...@gmx.de wrote:


On 2010-03-16, Bill Barker billwbar...@verizon.net wrote:



I was thinking of adding a localRepository=name to the mvn /
builder that allows projects to share a local repo when they can't be
trusted to use the central repo.  These would be cleaned when Gump
finishes (or maybe on startup).



Is it the same like installing the snapshot artifacts in the local
~/.m2 cache ?


Yes, I think so.  Only that we'd be using a directory other than ~/.m2
that would get purged after the Gump run has finished.



Yes, that is the idea.  It lets a group of projects that depend on each 
other's snapshot artifacts to install them in a local cache where they can 
then be found by M2, since M2 doesn't like to get snapshot artifacts from 
any of the remote repos that are currently mirrored.


This would also be helpful for M2 projects that define their own remote repo 
in the POM, that isn't mirrored, since they can't be trusted to use the 
common local cache (because if they have a dependency on an Ant-built 
project, and are the first to request it, it will get the versioned jar from 
their remote repo, and then other M2 projects will use that jar instead of 
the Gump-built jar).


This would have made setting up portals-pluto-trunk much easier, instead of 
the sordid hack I used to convince Gump to make it the last project to 
build.



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: r920715 - /gump/metadata/project/excalibur.xml

[Stefan Bodewig]

On 2010-03-16, Bill Barker billwbar...@verizon.net wrote:

 I was thinking of adding a localRepository=name to the mvn /
 builder that allows projects to share a local repo when they can't be
 trusted to use the central repo.  These would be cleaned when Gump
 finishes (or maybe on startup).

Sounds like a good idea.  It would probably solve the castor-xml case as
well when castor-xml can share the local repository with castor-core.

Stefan

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

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

[sebb]

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

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

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

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

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

maven.test.skip.exec is deprecated:

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

which is why I used skipTests.

  /mvn

  option project=commons-lang-2.x /




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

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

[Stefan Bodewig]

On 2010-03-15, sebb seb...@gmail.com wrote:

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

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

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

 maven.test.skip.exec is deprecated:

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

 which is why I used skipTests.

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

What is plugin version determined by?  The installed mvn version (2.2 by
now) or the project's POM?  skipTests would require Surefire 2.4 to work
and I don't know whether this is actually used by all projects.

Stefan

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

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

[sebb]

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

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


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


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

   maven.test.skip.exec is deprecated:

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

   which is why I used skipTests.


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

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

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

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

Good point, but Commons-parent 13 uses 2.5

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

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

  Stefan

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



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

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

[Stefan Bodewig]

On 2010-03-15, sebb seb...@gmail.com wrote:

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

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


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


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

 maven.test.skip.exec is deprecated:

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

 which is why I used skipTests.


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

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

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

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

 Good point, but Commons-parent 13 uses 2.5

I've reverted the commons-io project, if it works we can start moving
over other occurances of maven.test.skip.exec.  It wouldn't be the first
mvn property that failed to work as advertised in the Gump context
(project.build.finalName is one such example) - it may be that we just
don't understand Maven well enough, though.

Stefan

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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Stefan Bodewig]

On 2010-03-15, Bill Barker billwbar...@verizon.net wrote:

 --
 From: Stefan Bodewig bode...@apache.org
 Sent: Sunday, March 14, 2010 10:20 PM
 To: general@gump.apache.org
 Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

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

 Yeah, downloaded the src distro for maven 2.2.1, and it is that it is
 that the 'central' repo is disabled for SNAPSHOTs (and it is looking
 for a SNAPSHOT POM).  So Maven never asks to get it (even though it is
 there).

 Do I understand this correctly that with Maven 2.2 Gump will not be able
 to inject its own jars if the POM specifies a dependency on a SNAPSHOT
 version?

 I think that this is a setting for 'central', that it disables
 SNAPSHOT versions (understandable from the Maven prospective).  It's
 just that Maven won't download a SNAPSHOT version from 'central'.
 Reactor builds with SNAPSHOT should still work.

I see.  SNAPSHOTs then will likely be pulled from different repositories
and we'd need to make the Maven proxy intercept those as well.

 Briefly thought of overriding this in either the local or global
 settings, but then realized that I don't know enough about Maven to
 get it right in the first 10 tries ;).  That is why I was hoping that
 there is still a Maven guru lurking here.

Same here.

Stefan

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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Bill Barker]

--
From: Stefan Bodewig bode...@apache.org
Sent: Monday, March 15, 2010 8:01 AM
To: general@gump.apache.org
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-15, Bill Barker billwbar...@verizon.net wrote:


--
From: Stefan Bodewig bode...@apache.org
Sent: Sunday, March 14, 2010 10:20 PM
To: general@gump.apache.org
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml



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



Yeah, downloaded the src distro for maven 2.2.1, and it is that it is
that the 'central' repo is disabled for SNAPSHOTs (and it is looking
for a SNAPSHOT POM).  So Maven never asks to get it (even though it is
there).



Do I understand this correctly that with Maven 2.2 Gump will not be able
to inject its own jars if the POM specifies a dependency on a SNAPSHOT
version?



I think that this is a setting for 'central', that it disables
SNAPSHOT versions (understandable from the Maven prospective).  It's
just that Maven won't download a SNAPSHOT version from 'central'.
Reactor builds with SNAPSHOT should still work.


I see.  SNAPSHOTs then will likely be pulled from different repositories
and we'd need to make the Maven proxy intercept those as well.



Or, like for hudson, they just won't be found.  I was thinking of adding a 
localRepository=name to the mvn / builder that allows projects to share 
a local repo when they can't be trusted to use the central repo.  These 
would be cleaned when Gump finishes (or maybe on startup).


Then the projects could use a goal of 'install', and it looks like Maven 
will accept it for another project that wants to depend on that SNAPSHOT 
version.



Briefly thought of overriding this in either the local or global
settings, but then realized that I don't know enough about Maven to
get it right in the first 10 tries ;).  That is why I was hoping that
there is still a Maven guru lurking here.


Same here.

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: r920715 - /gump/metadata/project/excalibur.xml

[Stefan Bodewig]

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

 Yeah, downloaded the src distro for maven 2.2.1, and it is that it is
 that the 'central' repo is disabled for SNAPSHOTs (and it is looking
 for a SNAPSHOT POM).  So Maven never asks to get it (even though it is
 there).

Do I understand this correctly that with Maven 2.2 Gump will not be able
to inject its own jars if the POM specifies a dependency on a SNAPSHOT
version?

Stefan

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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Bill Barker]

--
From: Stefan Bodewig bode...@apache.org
Sent: Sunday, March 14, 2010 10:20 PM
To: general@gump.apache.org
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


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


Yeah, downloaded the src distro for maven 2.2.1, and it is that it is
that the 'central' repo is disabled for SNAPSHOTs (and it is looking
for a SNAPSHOT POM).  So Maven never asks to get it (even though it is
there).


Do I understand this correctly that with Maven 2.2 Gump will not be able
to inject its own jars if the POM specifies a dependency on a SNAPSHOT
version?



I think that this is a setting for 'central', that it disables SNAPSHOT 
versions (understandable from the Maven prospective).  It's just that Maven 
won't download a SNAPSHOT version from 'central'.  Reactor builds with 
SNAPSHOT should still work.


Briefly thought of overriding this in either the local or global settings, 
but then realized that I don't know enough about Maven to get it right in 
the first 10 tries ;).  That is why I was hoping that there is still a Maven 
guru lurking here.

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: r920715 - /gump/metadata/project/excalibur.xml

[Bill Barker]

--
From: Stefan Bodewig bode...@apache.org
Sent: Thursday, March 11, 2010 5:38 AM
To: general@gump.apache.org
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-11, Bill Barker billwbar...@verizon.net wrote:


If you have any ideas why portals-pluto-trunk can't find it's parent,


It isn't even trying to download it.  Since I don't know enough about
Maven I can't say why a repository may get disabled, but

[DEBUG] Skipping disabled repository central
[DEBUG] portals-pom: using locally installed snapshot
[DEBUG] Skipping disabled repository central
[DEBUG] Using mirror: http://localhost:8192/maven2 (id: gump-central)

sounds suspicios.



Yeah, downloaded the src distro for maven 2.2.1, and it is that it is that 
the 'central' repo is disabled for SNAPSHOTs (and it is looking for a 
SNAPSHOT POM).  So Maven never asks to get it (even though it is there). 
The work-arounds that I've seen are too complex for Gump, and the project is 
largely dormant, so for the moment will just let it fail.


Of course, if there are any Maven gurus lurking here with better ideas, 
would love to hear them.



In particular, if there was an access-log (that I haven't found), this
would be great.  The mvnrepo log doesn't show it at all, but looks
like it only logs 200 OK requests.


The proxy uses ju.logging and I think it should be logging to stdout by
default which should make it end up in Gump's own log file (since this
is the parent process).  I can't promise it would log failed requests,
though.

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: r920715 - /gump/metadata/project/excalibur.xml

[Stefan Bodewig]

On 2010-03-11, Bill Barker billwbar...@verizon.net wrote:

 If you have any ideas why portals-pluto-trunk can't find it's parent,

It isn't even trying to download it.  Since I don't know enough about
Maven I can't say why a repository may get disabled, but

[DEBUG] Skipping disabled repository central
[DEBUG] portals-pom: using locally installed snapshot
[DEBUG] Skipping disabled repository central
[DEBUG] Using mirror: http://localhost:8192/maven2 (id: gump-central)

sounds suspicios.

 In particular, if there was an access-log (that I haven't found), this
 would be great.  The mvnrepo log doesn't show it at all, but looks
 like it only logs 200 OK requests.

The proxy uses ju.logging and I think it should be logging to stdout by
default which should make it end up in Gump's own log file (since this
is the parent process).  I can't promise it would log failed requests,
though.

Stefan

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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Stefan Bodewig]

first of all: it worked ;-)

On 2010-03-10, Bill Barker billwbar...@verizon.net wrote:

 The maven-fortress-plugin runs with a goal of install' against the
 public local repo, so copies it's POM there as well as the jar file.

Yes, but it installs it as -SNAPSHOT version, not the released version
the excalibur projects have been looking for.

 Then M2 running on say excalibur-pool-impl sees it in the local repo,
 and thinks it has it already.

Shouldn't be since it has the wrong version.

 It then opens the POM, sees the wrong version number and throws a
 hissy fit.

I still think it must be something inside the jar. 8-)

 It's possible that restoring the jar, but removing the 'install' goal
 on maven-fortress-plugin will trick M2 into getting the proxied POM,
 but the built plugin.  I'm still working through how the mvnrepo proxy
 works, so this is just a guess.

Let me try to help you out WRT the proxy.

In general the proxy really only acts as a proxy using a few hard-coded
paths to identify known Maven repos based on the request's pathinfo.

Every jar in a Gump descriptor will publish a jar or POM to the repo
proxy after the project containing it has finished.  POMs that don't use
the jar-hack will not be published to the proxy at all.  Most of the
time this means mvn projects will see the original POMs of the released
versions but get the latest jars.

It looks as if such a combination would cause trouble for Maven plugins
since the jar has embeded version information (at least that's my
understanding of it).

 From: Stefan Bodewig bode...@apache.org
 Sent: Tuesday, March 09, 2010 12:53 AM

 The jar itself has been downloaded a few minutes before the build of
 excalibur-pool-impl so the installed version has been provided by the
 proxy.

 It shouldn't have been, unless the project that downloaded it used
 separateLocalRepository.

No, it has just been looking for a non-SNAPSHOT version since the plugin
build has only installed a -SNAPSHOT.

Stefan

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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Bill Barker]

--
From: Stefan Bodewig bode...@apache.org
Sent: Wednesday, March 10, 2010 12:27 AM
To: general@gump.apache.org
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


first of all: it worked ;-)



Yes, I didn't look to see that Gump was still running when I replied, so saw 
the old page :(.



On 2010-03-10, Bill Barker billwbar...@verizon.net wrote:


The maven-fortress-plugin runs with a goal of install' against the
public local repo, so copies it's POM there as well as the jar file.


Yes, but it installs it as -SNAPSHOT version, not the released version
the excalibur projects have been looking for.


Then M2 running on say excalibur-pool-impl sees it in the local repo,
and thinks it has it already.


Shouldn't be since it has the wrong version.



Yeah, wondered about that, but couldn't see where it was getting the file 
from, so I guess your right, and it is packaged with the plugin.



It then opens the POM, sees the wrong version number and throws a
hissy fit.


I still think it must be something inside the jar. 8-)


It's possible that restoring the jar, but removing the 'install' goal
on maven-fortress-plugin will trick M2 into getting the proxied POM,
but the built plugin.  I'm still working through how the mvnrepo proxy
works, so this is just a guess.


Let me try to help you out WRT the proxy.

In general the proxy really only acts as a proxy using a few hard-coded
paths to identify known Maven repos based on the request's pathinfo.

Every jar in a Gump descriptor will publish a jar or POM to the repo
proxy after the project containing it has finished.  POMs that don't use
the jar-hack will not be published to the proxy at all.  Most of the
time this means mvn projects will see the original POMs of the released
versions but get the latest jars.



If you have any ideas why portals-pluto-trunk can't find it's parent, I'd 
love to know them (but this is just to migrate projects off of the 1.0 
release, so isn't really important now that castor is building).  In 
particular, if there was an access-log (that I haven't found), this would be 
great.  The mvnrepo log doesn't show it at all, but looks like it only logs 
200 OK requests.


Of course, I'll do the grunt-work if I only knew the right grunt ;).


It looks as if such a combination would cause trouble for Maven plugins
since the jar has embeded version information (at least that's my
understanding of it).


From: Stefan Bodewig bode...@apache.org
Sent: Tuesday, March 09, 2010 12:53 AM



The jar itself has been downloaded a few minutes before the build of
excalibur-pool-impl so the installed version has been provided by the
proxy.



It shouldn't have been, unless the project that downloaded it used
separateLocalRepository.


No, it has just been looking for a non-SNAPSHOT version since the plugin
build has only installed a -SNAPSHOT.

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: r920715 - /gump/metadata/project/excalibur.xml

[Stefan Bodewig]

On 2010-03-09, Bill Barker billwbar...@verizon.net wrote:

 Don't think this is going to help.  It's complaining about the
 installed POM, not the artifact from the mvnrepo proxy.

It's complaining about Plugin's descriptor which I guess not to be the
POM but some sort of descriptor contained withing the jar.

The jar itself has been downloaded a few minutes before the build of
excalibur-pool-impl so the installed version has been provided by the
proxy.

This is guesswork, I know.

Stefan

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

Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

[Bill Barker]

--
From: Stefan Bodewig bode...@apache.org
Sent: Tuesday, March 09, 2010 12:53 AM
To: general@gump.apache.org
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-09, Bill Barker billwbar...@verizon.net wrote:


Don't think this is going to help.  It's complaining about the
installed POM, not the artifact from the mvnrepo proxy.


It's complaining about Plugin's descriptor which I guess not to be the
POM but some sort of descriptor contained withing the jar.



No, it's the POM.  The maven-fortress-plugin runs with a goal of 'install' 
against the public local repo, so copies it's POM there as well as the jar 
file.  Then M2 running on say excalibur-pool-impl sees it in the local repo, 
and thinks it has it already.  It then opens the POM, sees the wrong version 
number and throws a hissy fit.


It's possible that restoring the jar, but removing the 'install' goal on 
maven-fortress-plugin will trick M2 into getting the proxied POM, but the 
built plugin.  I'm still working through how the mvnrepo proxy works, so 
this is just a guess.



The jar itself has been downloaded a few minutes before the build of
excalibur-pool-impl so the installed version has been provided by the
proxy.



It shouldn't have been, unless the project that downloaded it used 
separateLocalRepository.



This is guesswork, I know.

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: r887813 - /gump/metadata/project/hudson.xml

[Stefan Bodewig]

On 2009-12-07, billbar...@apache.org wrote:

 having an install goal is useless with a separateLocalRepository.

Mostly.

It is useful for reactor builds, though.

 And I don't think anyone is interested enough to check the dependacies
 here

Probably not.

IIRC the main problem is that hudson doesn't use the Maven central repo
but a repository and our webapp doesn't act as a proxy for it.

Stefan

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

Re: svn commit: r887621 - /gump/metadata/project/commons-jexl-1.x.xml

[Niall Pemberton]

I also tried another approach to fix this at the same time - but which
change made this work - yours or mine?

   http://svn.apache.org/viewvc?view=revisionrevision=887616

I'm thinking of removing that id element and see if it still works
with my change.

Niall

On Sun, Dec 6, 2009 at 12:47 AM,  billbar...@apache.org wrote:
 Author: billbarker
 Date: Sun Dec  6 00:47:23 2009
 New Revision: 887621

 URL: http://svn.apache.org/viewvc?rev=887621view=rev
 Log:
 Let's try it without the version number and see if that makes maven happy

 Modified:
    gump/metadata/project/commons-jexl-1.x.xml

 Modified: gump/metadata/project/commons-jexl-1.x.xml
 URL: 
 http://svn.apache.org/viewvc/gump/metadata/project/commons-jexl-1.x.xml?rev=887621r1=887620r2=887621view=diff
 ==
 --- gump/metadata/project/commons-jexl-1.x.xml (original)
 +++ gump/metadata/project/commons-jexl-1.x.xml Sun Dec  6 00:47:23 2009
 @@ -28,7 +28,7 @@
     packageorg.apache.commons.jexl/package
     descriptionCommons Jexl 1.x/description
     mvn goal=package /
 -    jar name=target/commons-jexl-1.1.1-SNAPSHOT.jar 
 id=commons-jexl-1.1/
 +    jar name=target/commons-jexl-1.1.1-SNAPSHOT.jar id=commons-jexl/
     option project=ant/
     option project=commons-beanutils/
     option project=commons-collections/




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

Re: svn commit: r887621 - /gump/metadata/project/commons-jexl-1.x.xml

[Bill Barker]

I'm guessing that it is using mine at the moment, but I don't know maven 
well enough to be sure.  If yours works, then it is cleaner (my requires 
jexl-1.x to build before jexl so that the correct jar is in Gump's M2 
repository and that no project that depends on jexl-1.x switches to an M2 
build).


So +1 to trying it without the id.

- Original Message - 
From: Niall Pemberton niall.pember...@gmail.com

To: general@gump.apache.org
Sent: Sunday, December 06, 2009 11:11 AM
Subject: Re: svn commit: r887621 - 
/gump/metadata/project/commons-jexl-1.x.xml



I also tried another approach to fix this at the same time - but which
change made this work - yours or mine?

  http://svn.apache.org/viewvc?view=revisionrevision=887616

I'm thinking of removing that id element and see if it still works
with my change.

Niall

On Sun, Dec 6, 2009 at 12:47 AM,  billbar...@apache.org wrote:

Author: billbarker
Date: Sun Dec 6 00:47:23 2009
New Revision: 887621

URL: http://svn.apache.org/viewvc?rev=887621view=rev
Log:
Let's try it without the version number and see if that makes maven happy

Modified:
gump/metadata/project/commons-jexl-1.x.xml

Modified: gump/metadata/project/commons-jexl-1.x.xml
URL: 
http://svn.apache.org/viewvc/gump/metadata/project/commons-jexl-1.x.xml?rev=887621r1=887620r2=887621view=diff

==
--- gump/metadata/project/commons-jexl-1.x.xml (original)
+++ gump/metadata/project/commons-jexl-1.x.xml Sun Dec 6 00:47:23 2009
@@ -28,7 +28,7 @@
packageorg.apache.commons.jexl/package
descriptionCommons Jexl 1.x/description
mvn goal=package /
- jar name=target/commons-jexl-1.1.1-SNAPSHOT.jar 
id=commons-jexl-1.1/

+ jar name=target/commons-jexl-1.1.1-SNAPSHOT.jar id=commons-jexl/
option project=ant/
option project=commons-beanutils/
option project=commons-collections/





-
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: r817123 - /gump/metadata/project/tomcat-tc6.xml

[Bill Barker]

- Original Message - 
From: Stefan Bodewig bode...@apache.org

To: general@gump.apache.org
Sent: Sunday, September 20, 2009 9:06 PM
Subject: Re: svn commit: r817123 - /gump/metadata/project/tomcat-tc6.xml



On 2009-09-21, billbar...@apache.org wrote:


Try and convince the maven repo to serve up the correct servlet jars


We should probably remove the like-named projects from
jakarta-servletapi-5.xml and start migrating all projects that use the
jakarta-servlet-api project(s) over to tomcat-6's version.



+1  For a start, there don't seem that many M2 projects depending on these , 
and just seem to want the basic API, so shouldn't be to hard to switch them 
to TC6.



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

[Stefan Bodewig]

On 2009-09-08, s...@apache.org wrote:

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

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

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

Stefan

-
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

[Stefan Bodewig]

On 2009-09-08, sebb seb...@gmail.com wrote:

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

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

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

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

 It's used by Jelly.

 But what should it be?

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

Stefan

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

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

[sebb]

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

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

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

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

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

   It's used by Jelly.

   But what should it be?


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


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

  Stefan

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



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

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

[Bill Barker]

- Original Message - 
From: Stefan Bodewig bode...@apache.org

To: general@gump.apache.org
Sent: Sunday, August 30, 2009 7:56 PM
Subject: Re: svn commit: r809220 - /gump/metadata/project/commons-proper.xml



On 2009-08-30, billbar...@apache.org wrote:


Author: billbarker
Date: Sat Aug 29 23:05:13 2009
New Revision: 809220



URL: http://svn.apache.org/viewvc?rev=809220view=rev
Log:
It seems that ant includes the body in property statements now


Yes, is/was this causing problems?  If so, we (Ant) should at least flag
this under the could break older builds section for 1.8.0.



Yes, the older maven-1 generated build.xml files produce output like:
property name=distdir value=dist
/property

With the current HEAD of ant, this produces:
distdir=dist\n 



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

[Stefan Bodewig]

On 2009-08-31, Bill Barker billwbar...@verizon.net wrote:

 From: Stefan Bodewig bode...@apache.org

 On 2009-08-30, billbar...@apache.org wrote:

 It seems that ant includes the body in property statements now

 Yes, is/was this causing problems?

 Yes, the older maven-1 generated build.xml files produce output like:
 property name=distdir value=dist
 /property

I see.  We need to check for whitespace-only content and strip that if
necessary.  Should get fixed sometime later today.

Stefan

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

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

[Stefan Bodewig]

On 2009-08-30, billbar...@apache.org wrote:

 Author: billbarker
 Date: Sat Aug 29 23:05:13 2009
 New Revision: 809220

 URL: http://svn.apache.org/viewvc?rev=809220view=rev
 Log:
 It seems that ant includes the body in property statements now

Yes, is/was this causing problems?  If so, we (Ant) should at least flag
this under the could break older builds section for 1.8.0.

Stefan

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

Re: svn commit: r778326 - /gump/metadata/project/turbine-fulcrum.xml

[Stefan Bodewig]

On 2009-05-25, t...@apache.org wrote:

 Added JUnit dependency (seems to be missing)

 Modified:
 gump/metadata/project/turbine-fulcrum.xml

It seems to be missing in your POM, not (only) your Gump descriptor.
If mvn asked for JUnit t would get it, even if no dependency was
listed.

Stefan

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

Re: svn commit: r765058 - in /gump/metadata: project/hudson.xml repository/javanet.hudson.xml repository/javanet.svn.xml

[Stefan Bodewig]

On 2009-04-15, j...@apache.org wrote:

 It seems (to me) that Hudson needs its own repository.

not really.

 Add user information for access to its svn.

I'm not sure whether any other repository uses this, let's see whether
the authentication code in Gump's svn updater works.

 -  url https://svn.dev.java.net/svn//url
 +  urlhttps://svn.dev.java.net/svn/hudson/trunk//url

this could have been done using a dir-attribute on the svn tag in the
hudson module descriptor.

Stefan

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

Re: svn commit: r759456 - /gump/metadata/project/httpcomponents.xml

[Stefan Bodewig]

On 2009-03-30, Oleg Kalnichevski ol...@apache.org wrote:

 On Mon, 2009-03-30 at 06:24 +0200, Stefan Bodewig wrote:
 You really only need to add a junitreport element that points to the
 surefire target directory and all test reports are published.  Sorry
 it isn't documented in an obvious way.

 Did that (see commit messages), but surefire-reports link always pointed
 at an empty folder.

I'll take a look at that, hmm, looks as if there was just a directory
level missing.  The build log says

,
| Surefire report directory: 
/srv/gump/public/workspace/httpcomponents/httpcore/httpcore/target/surefire-reports
`

which is one httpcore more than the Gump descriptor contains.  I'll
fix that.  home doesn't apply to junitreport, maybe it should.

 I did try hard before giving up.

In no way did I want to question that.

Stefan

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

Re: svn commit: r759456 - /gump/metadata/project/httpcomponents.xml

[Oleg Kalnichevski]

On Mon, 2009-03-30 at 06:24 +0200, Stefan Bodewig wrote:
 On 2009-03-28, Oleg Kalnichevski ol...@apache.org wrote:
 
  On Sat, 2009-03-28 at 16:13 +0100, Stefan Bodewig wrote:
  Hi Oleg
 
  On 2009-03-28, ol...@apache.org wrote:
 
  URL: http://svn.apache.org/viewvc?rev=759456view=rev
  Log:
  Giving up on Gump
 
  Why is that, what is causing trouble to you?  I don't recall any
  specific incidents.
 
  There several reasons that led me to this decision.
 
  (1) Gump has been Maven2 unfriendly for quite some time.
 
 I'd say it is the other way around, but I'm certainly biased. 8-)
 
  Just a small example. Every change of an artifact version in a
  project's POM causes Gump build failure, requiring a manual update
  of the Gump metadata.  While not such a big deal, this can be quite
  a nuisance during the release process when so many things need to be
  taken care of.
 
 Yes, this is a pain.  We'd immediately fix that in Gump if only we
 could.  We've tried to set the artifact name related properties on the
 mvn command line (as we've been told to do), but it simply doesn't
 work.
 
  (2) Just recently HttpCompopnents Core build has been failing for
  several days in a row. Despite all my attempts to figure out _what_
  exactly was causing the failure, I just could not. All tests seemed to
  pass.
 
 Most likely a change upstream.
 

You see, guessing does not really help. I simply could not extract any
helpful information from the Gump report which could help me identify
the cause of the failure. 



  At the same time I could not find a way to get hold of the surefire
  reports to double-check. It was all just a bit too much for me and I
  gave up.
 
 You really only need to add a junitreport element that points to the
 surefire target directory and all test reports are published.  Sorry
 it isn't documented in an obvious way.
 

Did that (see commit messages), but surefire-reports link always pointed
at an empty folder.  

I did try hard before giving up.

Oleg


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

Re: svn commit: r759456 - /gump/metadata/project/httpcomponents.xml

[Oleg Kalnichevski]

On Sat, 2009-03-28 at 16:13 +0100, Stefan Bodewig wrote:
 Hi Oleg
 
 On 2009-03-28, ol...@apache.org wrote:
 
  Author: olegk
  Date: Sat Mar 28 11:40:36 2009
  New Revision: 759456
 
  URL: http://svn.apache.org/viewvc?rev=759456view=rev
  Log:
  Giving up on Gump
 
 Why is that, what is causing trouble to you?  I don't recall any
 specific incidents.
 

Hi Stefan

There several reasons that led me to this decision. 

(1) Gump has been Maven2 unfriendly for quite some time. Just a small
example. Every change of an artifact version in a project's POM causes
Gump build failure, requiring a manual update of the Gump metadata.
While not such a big deal, this can be quite a nuisance during the
release process when so many things need to be taken care of.

(2) Just recently HttpCompopnents Core build has been failing for
several days in a row. Despite all my attempts to figure out _what_
exactly was causing the failure, I just could not. All tests seemed to
pass. At the same time I could not find a way to get hold of the
surefire reports to double-check. It was all just a bit too much for me
and I gave up.

While I understand the unique value of Gump, Continuum is simply more
practical for multi-module Maven projects. 

Oleg

 Anyway, I have revertedy your changes since other projects might
 depend on httpcomponents, but I have removed the nag emails so you
 don't need to bother if it disturbs you.
 
 Many thanks for supporting Gump in the past
 
  Stefan


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

Re: svn commit: r759456 - /gump/metadata/project/httpcomponents.xml

[Stefan Bodewig]

On 2009-03-28, Oleg Kalnichevski ol...@apache.org wrote:

 On Sat, 2009-03-28 at 16:13 +0100, Stefan Bodewig wrote:
 Hi Oleg

 On 2009-03-28, ol...@apache.org wrote:

 URL: http://svn.apache.org/viewvc?rev=759456view=rev
 Log:
 Giving up on Gump

 Why is that, what is causing trouble to you?  I don't recall any
 specific incidents.

 There several reasons that led me to this decision.

 (1) Gump has been Maven2 unfriendly for quite some time.

I'd say it is the other way around, but I'm certainly biased. 8-)

 Just a small example. Every change of an artifact version in a
 project's POM causes Gump build failure, requiring a manual update
 of the Gump metadata.  While not such a big deal, this can be quite
 a nuisance during the release process when so many things need to be
 taken care of.

Yes, this is a pain.  We'd immediately fix that in Gump if only we
could.  We've tried to set the artifact name related properties on the
mvn command line (as we've been told to do), but it simply doesn't
work.

 (2) Just recently HttpCompopnents Core build has been failing for
 several days in a row. Despite all my attempts to figure out _what_
 exactly was causing the failure, I just could not. All tests seemed to
 pass.

Most likely a change upstream.

 At the same time I could not find a way to get hold of the surefire
 reports to double-check. It was all just a bit too much for me and I
 gave up.

You really only need to add a junitreport element that points to the
surefire target directory and all test reports are published.  Sorry
it isn't documented in an obvious way.

 While I understand the unique value of Gump, Continuum is simply more
 practical for multi-module Maven projects.

Gump and Continuum fill totally different needs.  IMHO it is no
either or but a use both.  Use Continuum for your nightly builds
and use Gump to detect the impact of your changes to your dependees or
changes in your dependencies to you.

Stefan

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

Re: svn commit: r759456 - /gump/metadata/project/httpcomponents.xml

[Stefan Bodewig]

Hi Oleg

On 2009-03-28, ol...@apache.org wrote:

 Author: olegk
 Date: Sat Mar 28 11:40:36 2009
 New Revision: 759456

 URL: http://svn.apache.org/viewvc?rev=759456view=rev
 Log:
 Giving up on Gump

Why is that, what is causing trouble to you?  I don't recall any
specific incidents.

Anyway, I have revertedy your changes since other projects might
depend on httpcomponents, but I have removed the nag emails so you
don't need to bother if it disturbs you.

Many thanks for supporting Gump in the past

 Stefan

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

AW: Re: svn commit: r735591 - /gump/metadata/project/velocity-engine.xml

[Jan.Materne]

Just for recap:
- by prepending ${basedir} to all relative paths you want to get absolute paths
- you calculate the string for ${basedir} with pathconvert
- pathconvert adds a ':' sign
Do you tried
  property name=basedir-os location=./

(I have only Windows so forgive my missing knowledge about the behaviour on 
Unix ;)


Jan

 -Ursprüngliche Nachricht-
 Von: news [mailto:n...@ger.gmane.org] Im Auftrag von Bill Barker
 Gesendet: Montag, 19. Januar 2009 08:27
 An: general@gump.apache.org
 Betreff: Re: svn commit: r735591 - 
 /gump/metadata/project/velocity-engine.xml
 
 The build script is overly complicated, but the relevant part is:
 
 project name=Velocity default=world basedir=.. 
 xmlns:artifact=urn:maven-
 artifact-ant
 
   path id=basedir-os
 pathelement location=${basedir} /
   /path
   !-- This is the relative base dir. This must be the root 
 of the   --
   !-- Velocity distribution. All relative pathes are 
 prefixed with  --
   !-- velocity.dir   
--
   pathconvert property=velocity.dir refid=basedir-os 
 targetos=unix/
 
 After enabling debug in Gump, I could see that Ant found the 
 right directory 
 for the pathconvert, but prepended a ':' character to it.  As 
 the comments 
 say, this is used to build paths for the rest of the script, 
 so none of the 
 resulting paths are valid.  The build.xml file lives in the 'build' 
 directory of the project, so .. is the srcdir from Gump's 
 point of view.
 
 Stefan Bodewig bode...@apache.org wrote in message 
 news:y1uab9nq38t@v30161.1blu.de...
  On 2009-01-19, billbar...@apache.org wrote:
 
  Attempt to work around what looks like an Ant bug so this builds
 
  Modified:
  gump/metadata/project/velocity-engine.xml
 
  What is going wrong, what do we need to fix in Ant?
 
  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