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

2020-05-29 Thread 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&view=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

2018-04-23 Thread 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

2018-04-23 Thread 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&view=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&r1=1829907&r2=1829908&view=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

2017-12-15 Thread 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

2017-12-14 Thread 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

2017-12-14 Thread 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

2017-12-14 Thread 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&filename=/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&filename=/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&revision=1817886
[3] 
http://svn.apache.org/viewvc/commons/proper/daemon/trunk/pom.xml?revision=1816118&view=markup
[4] http://maven.apache.org/plugins/maven-assembly-plugin/

2017-12-13 12:43 GMT+03:00  :
> Author: markt
> Date: Wed Dec 13 09:43:40 2017
> New Revision: 1817993
>
> URL: http://svn.apache.org/viewvc?rev=1817993&view=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&r1=1817992&r2=1817993&view=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

2017-09-18 Thread 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: 
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&view=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&r1=1808662&r2=1808663&view=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

2016-01-19 Thread William Barker
No problem. I've dealt with other projects that used this plugin

On Tuesday, January 19, 2016, Dominik Stadler 
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, >
> wrote:
>
> > Author: billbarker
> > Date: Tue Jan 19 02:32:30 2016
> > New Revision: 1725406
> >
> > URL: http://svn.apache.org/viewvc?rev=1725406&view=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&r1=1725405&r2=1725406&view=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

2016-01-19 Thread 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,  wrote:

> Author: billbarker
> Date: Tue Jan 19 02:32:30 2016
> New Revision: 1725406
>
> URL: http://svn.apache.org/viewvc?rev=1725406&view=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&r1=1725405&r2=1725406&view=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

2015-08-02 Thread Stefan Bodewig
On 2015-08-01,  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

2015-02-15 Thread William Barker
On Feb 15, 2015 10:47 AM,  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=1659978&r1=1659977&r2=1659978&view=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 @@
>
>
> -id="openssl" reference="jarpath"/>
> +id="openssl" reference="outputpath"/>
>  
>
> 
> @@ -145,7 +145,7 @@
>
>
> -id="openssl" reference="jarpath"/>
> +id="openssl" reference="outputpath"/>
>  
>
> 
> @@ -186,7 +186,7 @@
>
>
> -id="openssl" reference="jarpath"/>
> +id="openssl" reference="outputpath"/>
>  
>
> 
> @@ -227,7 +227,7 @@
>    
>
> -id="openssl" reference="jarpath"/>
> +id="openssl" reference="outputpath"/>
>  reference="home"/>
>  
>
> Modified: gump/metadata/project/tomcat-trunk.xml
> URL:
http://svn.apache.org/viewvc/gump/metadata/project/tomcat-trunk.xml?rev=1659978&r1=1659977&r2=1659978&view=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 @@
>
>
> -id="openssl" reference="jarpath"/>
> +id="openssl" reference="outputpath"/>
>  
>
> 
> @@ -143,7 +143,7 @@
>
>
> -id="openssl" reference="jarpath"/>
> +id="openssl" reference="outputpath"/>
>  
>
> 
> @@ -183,7 +183,7 @@
>
>
> -id="openssl" reference="jarpath"/>
> +id="openssl" reference="outputpath"/>
>  reference="home"/>
>  
>
>


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

2015-02-12 Thread Konstantin Kolinko
2015-02-13 1:02 GMT+03:00 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]
>> +  http://www.openssl.org/"/>
>> +  
>> +OpenSSL Encryption Library (Branch 1.0.2)
>> +  
>> +
>> +  > 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: svn commit: r1659380 - /gump/metadata/project/openssl-1.0.2.xml

2015-02-12 Thread 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]
> +  http://www.openssl.org/"/>
> +  
> +OpenSSL Encryption Library (Branch 1.0.2)
> +  
> +
> +   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: Change "metadata" external at Gump live to use relative URL

2015-02-11 Thread Konstantin Kolinko
2015-02-11 8:14 GMT+03:00 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.

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: Change "metadata" external at Gump live to use relative URL

2015-02-10 Thread 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



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

2015-02-10 Thread Konstantin Kolinko
2015-02-11 4:28 GMT+03:00 William Barker :
> On Feb 10, 2015 5:16 PM,  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=1658850&r1=1658849&r2=1658850&view=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 @@
>> >   from="Bill Barker <billbar...@apache.org>" />
>>   
>> + 
>> +   org.apache.catalina
>> +   
>> +  
>> +   id="tomcat-dbcp" />
>> +  > +id="tomcat-dbcp-src" reference="jarpath" />
>> +  > +  id="commons-daemon" />
>> +   project="commons-daemon"
>> +  id="native-distro" reference="outputpath" />
>> +  > +  id="native-distro" reference="outputpath" />
>> +  
>> +  
>> +  > +path="." />
>> +  > +path="." />
>> +  > + reference="home" />
>> +  
>> +  
>> +  
>
> Did you mean APR here?

Fixed. Thank you!

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

>> +  
>> +  
>> +  
>> +  
>> +  > +reference="home"/>
>> +
>> +
>> +   
>> +   
>> +
>> +   
>> +   
>> +
>> +   
>> +
>> +   
>> +   


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

2015-02-10 Thread William Barker
On Feb 10, 2015 5:16 PM,  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=1658850&r1=1658849&r2=1658850&view=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 @@
>from="Bill Barker <billbar...@apache.org>" />
>   
> + 
> +   org.apache.catalina
> +   
> +  
> +  
> +   +id="tomcat-dbcp-src" reference="jarpath" />
> +   +  id="commons-daemon" />
> +   +  id="native-distro" reference="outputpath" />
> +   +  id="native-distro" reference="outputpath" />
> +  
> +  
> +   +path="." />
> +   +path="." />
> +   + reference="home" />
> +  
> +  
> +  

Did you mean APR here?

> +  
> +  
> +  
> +  
> +   +reference="home"/>
> +
> +
> +   
> +   
> +
> +   
> +   
> +
> +   
> +
> +   
> +   
> +
> ++ from="Bill Barker <billbar...@apache.org>" />
> + 
>   
> org.apache.catalina
> 
>
>


Change "metadata" external at Gump live to use relative URL

2015-02-10 Thread 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

2014-06-20 Thread Stefan Bodewig
On 2014-06-20,  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



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

2013-12-20 Thread Vincent Hennebert

Hi,

thanks for your message.

On 20/12/13 01:35, David Crossley wrote:

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


Yes, that’s actually what I did, but I guess I was trying to be too
clever. First, I thought Tomcat explicitly added the dependencies
because it needed them for itself, while I could get away with
inherit="runtime" (which doesn’t seem to do what I expected).

Then I added the dependencies listed in checkstyle.xml to xml-fop.xml,
but that was apparently still not enough. Hopefully this attempt will be
the right one.

Thanks,
Vincent



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=1552445&r1=1552444&r2=1552445&view=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 @@


  
-
+
+
+
+
+
+
  
  
  




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

2013-12-19 Thread 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=1552445&r1=1552444&r2=1552445&view=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 @@
>
> reference="jarpath" id="checkstyle"/>
>  
> -
> +
> +
> +
> +
> +
> +
>  
>  
>  
> 
> 

-
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

2013-08-11 Thread Stefan Bodewig
On 2013-08-12, David Crossley wrote:

>>+  

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

2013-08-11 Thread 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=1509547&r1=1509546&r2=1509547&view=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 @@
>  
>
>  
> +  

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

>
>  org.apache.catalina
>  
> @@ -42,12 +43,12 @@
>id="native-distro" reference="outputpath" />
> id="junit" />
> -   - path="." />
> -   - path="." />
> -  

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

2012-03-21 Thread 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

2012-03-20 Thread Stefan Bodewig
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.

> 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



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

2012-03-20 Thread 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=1303274&view=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=1303274&r1=1303273&r2=1303274&view=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.
-->

-
+
  Google Guava
  http://code.google.com/p/guava-libraries/

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

-  http://guava-libraries.googlecode.com/svn/trunk/
+  https://code.google.com/p/guava-libraries/

  



-
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

2012-02-19 Thread Konstantin Kolinko (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/GUMP-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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



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

2012-02-19 Thread Konstantin Kolinko (Commented) (JIRA)

[ 
https://issues.apache.org/jira/browse/GUMP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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



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

2011-08-10 Thread Stefan Bodewig
On 2011-08-10,  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  into  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
s for those as well so we get the build order right.

>>

You meant basedir="jcs", right?

> -  
> -
> -
> -
> -  

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

2011-04-12 Thread Stefan Bodewig
On 2011-04-12, sebb wrote:

> On 11 April 2011 07:24,   wrote:
>> Author: bodewig
>> Date: Mon Apr 11 06:24:37 2011
>> New Revision: 1090947

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

> Sorry about that - not sure how that happened.

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: r1090947 - /gump/metadata/profile/gump.xml

2011-04-12 Thread sebb
On 11 April 2011 07:24,   wrote:
> Author: bodewig
> Date: Mon Apr 11 06:24:37 2011
> New Revision: 1090947
>
> URL: http://svn.apache.org/viewvc?rev=1090947&view=rev
> Log:
> revert rev 1090785 which changed way more than it intended

Sorry about that - not sure how that happened.

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

>
> Modified:
>    gump/metadata/profile/gump.xml
>
> Modified: gump/metadata/profile/gump.xml
> URL: 
> http://svn.apache.org/viewvc/gump/metadata/profile/gump.xml?rev=1090947&r1=1090946&r2=1090947&view=diff
> ==
> --- gump/metadata/profile/gump.xml (original)
> +++ gump/metadata/profile/gump.xml Mon Apr 11 06:24:37 2011
> @@ -111,11 +111,7 @@
>   
>   
>   
> -
>   
>   
>   
> @@ -318,6 +314,7 @@
>   
>
>   
> +  
>   
>   
>   
> @@ -342,6 +339,7 @@
>   
>   
>   
> +  
>   
>
>  
> @@ -383,11 +381,11 @@
>   
>   
>   
> -  
>
>  
>   
> -
> +  
> +  
>
>  
>   
> @@ -413,6 +411,7 @@
>   
>   
>   
> +  
>   
>   
>   
> @@ -481,7 +480,7 @@
>   
>   
>   
> -  
> +  
>   
>   
>   
> @@ -507,6 +506,7 @@
>   
>   
>   
> +  
>   
>   
>   
> @@ -519,6 +519,7 @@
>   
>   
>   
> +  
>   
>   
>   
>
>
>

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



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

2011-03-02 Thread sebb
On 2 March 2011 05:04, Stefan Bodewig  wrote:
> On 2011-03-01, Antoine Levy-Lambert wrote:
>
>> Apache Directory Server has a lot of maven projects in it and they do
>> a lot of refactoring.
>
> I know 8-)
>
>> Would there not be something to do to automate the maintenance of gump
>> descriptors for maven based projects ?
>
>> Or even better, could gump be made able to read parent pom.xml files
>> directly and reinterpret them as gump metadata ?
>
> The main problem is the mismatch of ids.  Gump's id space is flat and
> Maven has the tuple of groupId and artifactId.  In many cases we can use
> the artifactId but it is not always possible as things tend to clash
> from time to time (junit-addons is one such example).  I don't see an
> automated way to resolve this.
>
> Another problem is writing a POM parser for Gump that recursively chased
> down parent POMs and knew how to consider the dependencies of plugins
> (almost all mvn projects depend on Velocity via the site plugin).
>
>> I do not have CPU cycles to develop that
>
> Me neither, sorry.

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

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

But I don't currently have that knowledge.

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

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



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

2011-03-01 Thread 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: r1075910 - in /gump/metadata/project: directory-apacheds.xml directory-shared.xml

2011-03-01 Thread 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=1075910&view=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: r1068427 - /gump/metadata/project/xml-fop.xml

2011-02-08 Thread Stefan Bodewig
On 2011-02-08,  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

2011-01-10 Thread Stefan Bodewig
Hi Colm,

On 2011-01-10,  wrote:

> URL: http://svn.apache.org/viewvc?rev=1057143&view=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=1057143&r1=1057142&r2=1057143&view=diff
> ==
> --- gump/metadata/project/santuario.xml (original)
> +++ gump/metadata/project/santuario.xml Mon Jan 10 10:25:37 2011
> @@ -35,7 +35,7 @@
>
>  

> -
> +

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)

2010-11-24 Thread Stefan Bodewig
On 2010-11-19, Stefan Bodewig wrote:

> On 2010-11-19,  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)

2010-11-19 Thread Stefan Bodewig
On 2010-11-19,  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

2010-11-16 Thread 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

2010-11-15 Thread sebb
On 15 November 2010 04:59,   wrote:
> Author: bodewig
> Date: Mon Nov 15 04:59:23 2010
> New Revision: 1035144
>
> URL: http://svn.apache.org/viewvc?rev=1035144&view=rev
> Log:
> make it well-formed

Sorry about that - missed the embedded comment.

>
> Modified:
>    gump/metadata/project/commons-proper.xml
>
> Modified: gump/metadata/project/commons-proper.xml
> URL: 
> http://svn.apache.org/viewvc/gump/metadata/project/commons-proper.xml?rev=1035144&r1=1035143&r2=1035144&view=diff
> ==
> --- gump/metadata/project/commons-proper.xml (original)
> +++ gump/metadata/project/commons-proper.xml Mon Nov 15 04:59:23 2010
> @@ -947,7 +947,6 @@
>     
>     
>     
> -    
>     
>     
>     
>
>
>

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



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

2010-09-27 Thread Stefan Bodewig
On 2010-09-27, sebb wrote:

> On 27 September 2010 11:48, Stefan Bodewig  wrote:
>> On 2010-09-27, sebb wrote:

>>> On 27 September 2010 10:07,   wrote:

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

>> 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: r1001631 - /gump/metadata/project/checkstyle.xml

2010-09-27 Thread sebb
On 27 September 2010 11:56, Maarten Coene  wrote:
> If the pattern has to be a regular expression, it should be:
> 

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

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

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

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



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

2010-09-27 Thread sebb
On 27 September 2010 11:48, Stefan Bodewig  wrote:
> On 2010-09-27, sebb wrote:
>
>> On 27 September 2010 10:07,   wrote:
>
>>> I don't know why wildcards sometimes don't seem to work
>
>>> -    >> +    
>> Perhaps they don't work because of the -SNAPSHOT suffix?
>
> No, that works in several other projects.  And the wildcard should still
> match anyway (that's why there is a T in the group).
>

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

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

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

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

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



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

2010-09-27 Thread Maarten Coene
If the pattern has to be a regular expression, it should be:


Maarten

--- On Mon, 9/27/10, Stefan Bodewig  wrote:

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




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



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

2010-09-27 Thread Stefan Bodewig
On 2010-09-27, sebb wrote:

> On 27 September 2010 10:07,   wrote:

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

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

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

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

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

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



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

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

2010-09-21 Thread Niall Pemberton
On Tue, Sep 21, 2010 at 10:30 AM, Stefan Bodewig  wrote:
> On 2010-09-21, Niall Pemberton wrote:
>
>> On Tue, Sep 21, 2010 at 8:28 AM,   wrote:
>>> Author: bodewig
>>> Date: Tue Sep 21 07:28:24 2010
>>> New Revision: 999257
>
>>> URL: http://svn.apache.org/viewvc?rev=999257&view=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
>
> 
>
> 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

2010-09-21 Thread Stefan Bodewig
On 2010-09-21, Niall Pemberton wrote:

> On Tue, Sep 21, 2010 at 8:28 AM,   wrote:
>> Author: bodewig
>> Date: Tue Sep 21 07:28:24 2010
>> New Revision: 999257

>> URL: http://svn.apache.org/viewvc?rev=999257&view=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



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.

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.

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

2010-09-21 Thread Niall Pemberton
On Tue, Sep 21, 2010 at 8:28 AM,   wrote:
> Author: bodewig
> Date: Tue Sep 21 07:28:24 2010
> New Revision: 999257
>
> URL: http://svn.apache.org/viewvc?rev=999257&view=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=999257&r1=999256&r2=999257&view=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 @@
>   
>   
>     
> +    
>      id="commons-beanutils-core"/>
>   
>
>
>
>

-
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

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

Sorry ...

> The commons-beanutils project has a  element that points at
> beanutils/dist - that's why the .. was needed -  and  are
> resolved relative to .
>
> commons-jci doesn't have a  element so its home dir is the checked
> out trunks directory.

... thanks for the explanation.

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

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



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

2010-09-14 Thread Stefan Bodewig
On 2010-09-14,  wrote:

> -
> +

Uhm, no.  I've reverted that part.

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

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

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

2010-07-05 Thread 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

2010-07-03 Thread 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: r960141 - /gump/metadata/project/forrest.xml

2010-07-03 Thread Stefan Bodewig
On 2010-07-03,  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: r953937 - /gump/metadata/project/excalibur.xml

2010-06-14 Thread 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

2010-06-12 Thread Bill Barker



--
From: 
Sent: Friday, June 11, 2010 10:18 PM
To: 
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=953937&view=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

2010-05-31 Thread 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,

>  

> 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: r949452 - in /gump/metadata: profile/gump.xml project/logging-log4j-2.xml

2010-05-31 Thread Curt Arnold

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

> On 2010-05-30,  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,

 

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

2010-05-30 Thread Stefan Bodewig
On 2010-05-30,  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: r941556 - /gump/metadata/project/apache-httpd.xml

2010-05-05 Thread Stefan Bodewig
On 2010-05-06,  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: r941172 - in /gump/metadata/project: apache-httpd.xml logging-log4cxx.xml

2010-05-05 Thread Stefan Bodewig
On 2010-05-05, Bill Barker  wrote:

>> URL: http://svn.apache.org/viewvc?rev=941172&view=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: r941172 - in /gump/metadata/project: apache-httpd.xml logging-log4cxx.xml

2010-05-05 Thread Bill Barker



--
From: 
Sent: Wednesday, May 05, 2010 12:05 AM
To: 
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=941172&view=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=941172&r1=941171&r2=941172&view=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 @@

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


-
+
  

  
@@ -41,8 +41,8 @@
  
  
-  
+  
  


Modified: gump/metadata/project/logging-log4cxx.xml
URL: 
http://svn.apache.org/viewvc/gump/metadata/project/logging-log4cxx.xml?rev=941172&r1=941171&r2=941172&view=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 @@
  
  
-  
+  
  


@@ -42,7 +42,7 @@



-
+


@@ -55,8 +55,8 @@
  
  
-  
+  
  


@@ -66,7 +66,7 @@



-
+


@@ -79,8 +79,8 @@
  
  
-  
+  
  
  

@@ -91,7 +91,7 @@



-
+


@@ -106,11 +106,11 @@

  
  
-  reference="home"/>
+  




-
+

  





-
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

2010-04-16 Thread Stefan Bodewig
On 2010-04-16, Stefan Bodewig  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: r934914 - in /gump/metadata/project: db-ojb.xml jakarta-slide.xml

2010-04-16 Thread Stefan Bodewig
On 2010-04-16, sebb  wrote:

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

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

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

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

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

2010-04-16 Thread sebb
On 16/04/2010, bode...@apache.org  wrote:
> Author: bodewig
>  Date: Fri Apr 16 14:27:48 2010
>  New Revision: 934914
>
>  URL: http://svn.apache.org/viewvc?rev=934914&view=rev
>  Log:
>  remove references to commons-transaction
>
>  Modified:
> gump/metadata/project/db-ojb.xml
> gump/metadata/project/jakarta-slide.xml

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

>  Modified: gump/metadata/project/db-ojb.xml
>  URL: 
> http://svn.apache.org/viewvc/gump/metadata/project/db-ojb.xml?rev=934914&r1=934913&r2=934914&view=diff
>  
> ======
>  --- gump/metadata/project/db-ojb.xml (original)
>  +++ gump/metadata/project/db-ojb.xml Fri Apr 16 14:27:48 2010
>  @@ -51,7 +51,6 @@
>  
>  
>  
>  -
>  
>  
>  
>  @@ -117,7 +116,6 @@
>  
>  
>  
>  -
>  
>  
>  
>
>  Modified: gump/metadata/project/jakarta-slide.xml
>  URL: 
> http://svn.apache.org/viewvc/gump/metadata/project/jakarta-slide.xml?rev=934914&r1=934913&r2=934914&view=diff
>  
> ==
>  --- gump/metadata/project/jakarta-slide.xml (original)
>  +++ gump/metadata/project/jakarta-slide.xml Fri Apr 16 14:27:48 2010
>  @@ -41,7 +41,6 @@
>  
>  
>  
>  -
>  
>  
>  
>
>
>

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



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

2010-03-19 Thread Bill Barker



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


On 2010-03-19, Antoine Levy Lambert  wrote:


On 2010-03-16, Bill Barker  wrote:



I was thinking of adding a localRepository="name" to the 
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

2010-03-19 Thread Stefan Bodewig
On 2010-03-19, Antoine Levy Lambert  wrote:

>> On 2010-03-16, Bill Barker  wrote:

>>> I was thinking of adding a localRepository="name" to the 
>>> 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

2010-03-19 Thread 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  wrote:

  

I was thinking of adding a localRepository="name" to the 
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

2010-03-18 Thread Stefan Bodewig
On 2010-03-16, Bill Barker  wrote:

> I was thinking of adding a localRepository="name" to the 
> 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

2010-03-15 Thread Bill Barker



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


On 2010-03-15, Bill Barker  wrote:


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



On 2010-03-13, Bill Barker  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  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

2010-03-15 Thread Stefan Bodewig
On 2010-03-15, Bill Barker  wrote:

> --
> From: "Stefan Bodewig" 
> Sent: Sunday, March 14, 2010 10:20 PM
> To: 
> Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

>> On 2010-03-13, Bill Barker  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: r923057 - /gump/metadata/project/commons-proper.xml

2010-03-15 Thread Stefan Bodewig
On 2010-03-15, sebb  wrote:

> On 15/03/2010, Stefan Bodewig  wrote:
>> On 2010-03-15, sebb  wrote:

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


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


  -  
> 

>>> maven.test.skip.exec is deprecated:

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

>>> which is why I used skipTests.


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

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

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

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

> Good point, but Commons-parent 13 uses 2.5

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

2010-03-15 Thread sebb
On 15/03/2010, Stefan Bodewig  wrote:
> On 2010-03-15, sebb  wrote:
>
>  > On 15/03/2010, bode...@apache.org  wrote:
>
>
> >>  URL: http://svn.apache.org/viewvc?rev=923057&view=rev
>  >>  Log:
>  >>  canonical property to skip tests in mvn
>
>
> >>  -  
>  >>  + 
>
>  > maven.test.skip.exec is deprecated:
>
>  > 
> http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#skipExec
>
>  > which is why I used skipTests.
>
>
> I didn't know that and wanted things to be consistent - we use the now
>  deprecated version all over the place.
>
>  What is plugin version determined by?  The installed mvn version (2.2 by
>  now) or the project's POM?

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

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

Good point, but Commons-parent 13 uses 2.5

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

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

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

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



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

2010-03-15 Thread Stefan Bodewig
On 2010-03-15, sebb  wrote:

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

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

>>  -  
>>  + 

> maven.test.skip.exec is deprecated:

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

> which is why I used skipTests.

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

What is plugin version determined by?  The installed mvn version (2.2 by
now) or the project's POM?  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

2010-03-15 Thread sebb
On 15/03/2010, bode...@apache.org  wrote:
> Author: bodewig
>  Date: Mon Mar 15 05:23:18 2010
>  New Revision: 923057
>
>  URL: http://svn.apache.org/viewvc?rev=923057&view=rev
>  Log:
>  canonical property to skip tests in mvn
>
>  Modified:
> gump/metadata/project/commons-proper.xml
>
>  Modified: gump/metadata/project/commons-proper.xml
>  URL: 
> http://svn.apache.org/viewvc/gump/metadata/project/commons-proper.xml?rev=923057&r1=923056&r2=923057&view=diff
>  
> ======
>  --- gump/metadata/project/commons-proper.xml (original)
>  +++ gump/metadata/project/commons-proper.xml Mon Mar 15 05:23:18 2010
>  @@ -449,7 +449,7 @@
>  Commons I/O Utility Package
>
>  
>  -  
>  +  

maven.test.skip.exec is deprecated:

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

which is why I used skipTests.

>  
>
>  
>
>
>

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



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

2010-03-14 Thread Bill Barker



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


On 2010-03-13, Bill Barker  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

2010-03-14 Thread Stefan Bodewig
On 2010-03-13, Bill Barker  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

2010-03-12 Thread Bill Barker



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


On 2010-03-11, Bill Barker  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

2010-03-11 Thread Stefan Bodewig
On 2010-03-11, Bill Barker  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

2010-03-10 Thread Bill Barker



--
From: "Stefan Bodewig" 
Sent: Wednesday, March 10, 2010 12:27 AM
To: 
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  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  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 -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" 
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

2010-03-10 Thread Stefan Bodewig
first of all: it worked ;-)

On 2010-03-10, Bill Barker  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  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 -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" 
> 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

2010-03-09 Thread Bill Barker



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


On 2010-03-09, Bill Barker  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: r920715 - /gump/metadata/project/excalibur.xml

2010-03-09 Thread Stefan Bodewig
On 2010-03-09, Bill Barker  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

2010-03-08 Thread Bill Barker
Don't think this is going to help.  It's complaining about the installed 
POM, not the artifact from the mvnrepo proxy.


--
From: 
Sent: Monday, March 08, 2010 10:58 PM
To: 
Subject: svn commit: r920715 - /gump/metadata/project/excalibur.xml


Author: bodewig
Date: Tue Mar  9 06:58:35 2010
New Revision: 920715

URL: http://svn.apache.org/viewvc?rev=920715&view=rev
Log:
Maven 2.2 has become more picky about plugin versions or so it seems. 
Stop publishing the fortress plugin.


Modified:
   gump/metadata/project/excalibur.xml

Modified: gump/metadata/project/excalibur.xml
URL: 
http://svn.apache.org/viewvc/gump/metadata/project/excalibur.xml?rev=920715&r1=920714&r2=920715&view=diff

==
--- gump/metadata/project/excalibur.xml (original)
+++ gump/metadata/project/excalibur.xml Tue Mar  9 06:58:35 2010
@@ -863,7 +863,7 @@



-
+







-
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

2009-12-11 Thread Niall Pemberton
On Mon, Dec 7, 2009 at 12:07 AM, Bill Barker  wrote:
> 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".

OK done, lets see what happens.

Niall

> - Original Message - From: "Niall Pemberton"
> 
> To: 
> 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=revision&revision=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,   wrote:
>>
>> Author: billbarker
>> Date: Sun Dec 6 00:47:23 2009
>> New Revision: 887621
>>
>> URL: http://svn.apache.org/viewvc?rev=887621&view=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=887621&r1=887620&r2=887621&view=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 @@
>> org.apache.commons.jexl
>> Commons Jexl 1.x
>> 
>> - > id="commons-jexl-1.1"/>
>> + 
>> 
>> 
>> 
>>
>>
>>
>
> -
> 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: r887813 - /gump/metadata/project/hudson.xml

2009-12-07 Thread Stefan Bodewig
On 2009-12-07,  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

2009-12-06 Thread 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" 

To: 
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=revision&revision=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,   wrote:

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

URL: http://svn.apache.org/viewvc?rev=887621&view=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=887621&r1=887620&r2=887621&view=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 @@
org.apache.commons.jexl
Commons Jexl 1.x

- id="commons-jexl-1.1"/>

+ 








-
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: r887621 - /gump/metadata/project/commons-jexl-1.x.xml

2009-12-06 Thread 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=revision&revision=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,   wrote:
> Author: billbarker
> Date: Sun Dec  6 00:47:23 2009
> New Revision: 887621
>
> URL: http://svn.apache.org/viewvc?rev=887621&view=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=887621&r1=887620&r2=887621&view=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 @@
>     org.apache.commons.jexl
>     Commons Jexl 1.x
>     
> -     id="commons-jexl-1.1"/>
> +    
>     
>     
>     
>
>
>

-
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

2009-09-21 Thread Bill Barker


- Original Message - 
From: "Stefan Bodewig" 

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



On 2009-09-21,  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: r817123 - /gump/metadata/project/tomcat-tc6.xml

2009-09-20 Thread Stefan Bodewig
On 2009-09-21,  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.

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

2009-09-08 Thread sebb
On 08/09/2009, Stefan Bodewig  wrote:
> On 2009-09-08, sebb  wrote:
>
>  > On 08/09/2009, Stefan Bodewig  wrote:
>  >> On 2009-09-08,  wrote:
>
>  >>> No longer using Ant build now that Jexl 2.0 is the trunk version
>  >>> Initial stab at M2 build
>
>  
>  
>
>  >>  If anybody depends on it and is supposed to use the generated jar, yes.
>
>  > It's used by Jelly.
>
>  > But what should it be?
>
>
> I don't think I understand the question.  The  element should point
>  to the jar created by the build process.  Given that we don't have any
>  influence on the jar name in mvn builds, you must use the (-SNAPSHOT)
>  version of the POM - and update the jar element whenever the POM is
>  changed.
>

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

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

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



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

2009-09-08 Thread Stefan Bodewig
On 2009-09-08, sebb  wrote:

> On 08/09/2009, Stefan Bodewig  wrote:
>> On 2009-09-08,  wrote:

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




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

> It's used by Jelly.

> But what should it be?

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

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

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

It's used by Jelly.

But what should it be?


>  Otherwise it is optional.
>
>  Stefan
>
>  -
>  To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
>  For additional commands, e-mail: general-h...@gump.apache.org
>
>

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



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

2009-09-08 Thread Stefan Bodewig
On 2009-09-08,  wrote:

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

>+
>+

If anybody depends on it and is supposed to use the generated jar, yes.
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: r809220 - /gump/metadata/project/commons-proper.xml

2009-08-31 Thread Stefan Bodewig
On 2009-08-31, Bill Barker  wrote:

> From: "Stefan Bodewig" 

>> On 2009-08-30,  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:
> 
> 

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

2009-08-30 Thread Bill Barker


- Original Message - 
From: "Stefan Bodewig" 

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



On 2009-08-30,  wrote:


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



URL: http://svn.apache.org/viewvc?rev=809220&view=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:



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

2009-08-30 Thread Stefan Bodewig
On 2009-08-30,  wrote:

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

> URL: http://svn.apache.org/viewvc?rev=809220&view=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

2009-05-25 Thread Stefan Bodewig
On 2009-05-25,  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



  1   2   3   >