Re: Board Report Draft

[Konstantin Kolinko]

вт, 9 мар. 2021 г. в 11:10, Stefan Bodewig :
>
> Hi all
>
> the report is due tomorrow. Th current draft (basically a copy of last
> month's report) is at
>
> https://cwiki.apache.org/confluence/display/GUMP/20210317

Looks OK.

The new VM is "Ubuntu 20.04"?

https://gump.apache.org/
The front page in "When does Gump run?" still says "Ubuntu Linux 18.04".

> I'm sorry that I seem to be getting worse with preparing the reports in
> a timely manner.

Thank you for your work, Stefan!

Best regards,
Konstantin Kolinko

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

Re: Where are we going?

[Konstantin Kolinko]

сб, 7 мар. 2020 г. в 18:35, Stefan Bodewig :
>
> Hi all
>
> nowadays Gump has become a tool that really only gets used by Tomcat. As
> long as it is useful for Tomcat this is probably fine. But is this the
> future of this project? Honestly, I haven't got any other vision to
> share.
>
> I wonder whether this in any way affects Gump's position of an Apache
> TLP. We've always been a special kind of project, more like an
> infrastructure service than a project that creates releases.


I asked some people at conferences whether they know about Apache Gump
and they don't. It is a bit frustrating.

The task of building the latest version of your project against the
latest versions of other projects does exist, and people are using
some tools, but not this one. (I was talking about some project built
by Maven, so the built was probably managed via Jenkins.)

It may help to actually make a release of Gump.

As of now, I am not really sure how to install the tool, what are its
requirements. How to start with some small configuration that does not
require 9 hours for a build. I can find that from the source code,
with my experience, but it is not easy. A lot of documentation is
outdated.

Best regards,
Konstantin Kolinko

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

Re: Borad Report Draft

[Konstantin Kolinko]

сб, 7 мар. 2020 г. в 18:25, Stefan Bodewig :
>
> Hi all
>
> https://cwiki.apache.org/confluence/display/GUMP/20200318
>
> is the draft of what I'm going to submit next Wednesday.

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

[Konstantin Kolinko]

Hi, Mark!

To dev@tomcat, cc: general@gump.


The result of this change is that Gump building Tomcat downloads
tar.gz for Commons-Daemon from mirrors.
The logs [1]:
[[[
trydownload:
  [get] Getting:
http://www.apache.org/dyn/closer.lua?action=download=/commons/daemon/source/commons-daemon-1.1.0-native-src.tar.gz
  [get] To:
/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs/download-1488937973.tmp
  [get] 
http://www.apache.org/dyn/closer.lua?action=download=/commons/daemon/source/commons-daemon-1.1.0-native-src.tar.gz
moved to 
http://mirror.novg.net/apache//commons/daemon/source/commons-daemon-1.1.0-native-src.tar.gz
]]]


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

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

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


The "mvn package" command used by Gump does not build the src.tar.gz file.

The file can be built by "mvn assembly:single" command, [4]
but HOWTO-RELEASE.txt file does not mention it so I wonder what is
actually used by Commons Daemon here.

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



Alternatively, a question is whether the "deploy" target in Tomcat
actually has a need to copy the *.tar.gz files to CATALINA_HOME/bin/.
Those source file are needed when redistributing Tomcat, but they are
not actually needed when running it.



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

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

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

Re: Board Report

[Konstantin Kolinko]

2017-11-30 17:21 GMT+03:00 Stefan Bodewig <bode...@apache.org>:
> Hi all
>
> current draft is
> https://wiki.apache.org/gump/Drafts/BoardReports/20171220 - I'll have to
> submit it in about two weeks.
>
> Back when vmgump failed in September I talked about asking projects
> whether they still see value in Gump but never got my act together. This
> time I've put it into the report to increase the chance of actually
> doing it.

Looks OK.
I think it would be better to mention the date when hickup happened,

s/After a hickup the service seems to be good again./After a hickup in
September 2017 the service seems to be good again./

https://lists.apache.org/thread.html/4b9c718ee5eaa31972b072fb39213d51dc9af84c6c5d4448a9411e17@%3Cgeneral.gump.apache.org%3E


Best regards,
Konstantin Kolinko

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

Re: ASF Board Report Draft

[Konstantin Kolinko]

2017-03-08 14:18 GMT+03:00 Stefan Bodewig <bode...@apache.org>:
> Hi all
>
> for some reason I'm pretty late this time around:
> https://wiki.apache.org/gump/Drafts/BoardReports/20170315
>
> I'll submit the report pretty soon, likely within the next 24 hours.

Looks good.

Several questions:

"vmgump has been replaced with a new VM with most of the installation
being automated via Puppet."

1. Maybe mention the new VM name?

- "with a new VM"
+ "with a new VM (vmgump-vm3)"

2. Is the version information at the title page of Gump site correct: ?
http://gump.apache.org/#When+does+Gump+run%3F

I mean the following line:
"Apache (vmgump - Ubuntu Linux 14.04)"

Looking for clues at Gump run summary page, and at a Tomcat ServerInfo test:
http://vmgump-vm3.apache.org/

Operating System (Name):  posix

http://vmgump.apache.org/tomcat-trunk/tomcat-trunk-test-nio/gump_file/TEST-org.apache.catalina.util.TestServerInfo.NIO.txt.html

OS Name:Linux
OS Version: 3.19.0-25-generic
Architecture:   amd64
JVM Version:1.8.0_121-b13
JVM Vendor: Oracle Corporation


It is certainly Java 8, but I cannot verify what the OS version is.


3. "with most of the installation being automated via Puppet."

"with most of" means that something is not automated.

Are there essential bits of configuration that are not automated?


Best regards,
Konstantin Kolinko

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

Statistics from the recent Gump run

[Konstantin Kolinko]

Hi !

Just FYI.

The git issues should have been cleared.

Here are statistics from recent run of Gump.
http://vmgump.apache.org/gump/public/buildLog.html

> This Apache Gump(TM) run is complete. It started at Fri, 22 Apr 2016 00:00:09 
> (UTC) and ended at Fri, 22 Apr 2016 10:11:29 (UTC).

The build ran for 10 hrs. This includes time to do fresh checkouts of
all projects that use git.

> Overall project success : 95.85%

Projects: 193
Successes: 154 (79.79%)
Failures: 04 (2.07%)
Prereqs: 04 (2.07%)
No Works: 00 (0.00%)
Packages: 31 (16.06%)



The four failed projects:
1.) apache-httpd-make
I think it is caused by recent changes in OpenSSL library.

2.) compress-antlib-test
A long standing issue.

[au:antunit] Target: testAntlibZipFileSet  FAILED  (x many times, An
inherited test?)
[au:antunit] Target: testCoreZipFileSet  FAILED  (x many times, An
inherited test?)
[au:antunit] Target: testResourceProperties  FAILED

I guess that this may be related to running on Java 8, similar to
https://issues.apache.org/jira/browse/COMPRESS-326
https://github.com/apache/commons-compress/commit/a2cda30

3.) and 4.) tomcat-tc8.0.x-test-apr and tomcat-tc8.0.x-test-nio.

   [concat] Testsuites with failed tests:
   [concat] TEST-org.apache.tomcat.websocket.TestWsWebSocketContainer.APR.txt

   [concat] Testsuites with failed tests:
   [concat] TEST-org.apache.tomcat.websocket.TestWsWebSocketContainer.NIO.txt

An occasional failure. It may go away in a next run. In all cases it
fails at the following assertion:

junit.framework.AssertionFailedError: expected:<0> but was:<1>
at 
org.apache.tomcat.websocket.WebSocketBaseTest.checkBackgroundProcessHasStopped(WebSocketBaseTest.java:43)


The 4 projects skipped due to prereq failures:
apache-httpd-make-install
tomcat-jk-native-buildconf
tomcat-jk-native-configure
tomcat-jk-native

Best regards,
Konstantin Kolinko

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

Cleanup Ant source directory at vmgump (Permissions issue writing to Git reflog file)

[Konstantin Kolinko]

Hi!

"update_ant" step is failing with

error: Unable to append to .git/logs/refs/remotes/origin/master:
Permission denied

http://vmgump.apache.org/gump/public/ant/
http://vmgump.apache.org/gump/public/ant/gump_work/update_ant.html

I guess that it is really a permission error, as the message says.

Can somebody cleanup that directory, so that a fresh copy is cloned
from git repository?

Working Directory: /srv/gump/public/workspace/cvs/ant


The failing operation is Git trying to append to a reflog file. If
this issue affects more than one project, I think we can disable git
reflogs by setting "core.logAllRefUpdates" configuration property to
false, as Git manual says. [1]

[1] https://git-scm.com/docs/git-config

Best regards,
Konstantin Kolinko

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

Re: Gump is building stale Checkstyle sources (and other GitHub projects)

[Konstantin Kolinko]

Hi!

Git reset is a good thing.  It is "git pull URL branch" here that is wrong.

The correct pull command will be "git pull" or "git pull origin",  but
not "git pull URL" that is currently used.

I think the way to go is "git fetch" + "git reset".

My idea is to

1. Update refs/remotes/origin/ to point to tip of remote branch.
This is what "git fetch" does.

(git pull also does that as it is actually a combination of "git
fetch" + "git merge")


2. Align local branch with remote one.
This is done by "git reset --hard".

I think that this is the fastest way. We do not need the "merge" part
of git pull, as we do not do any local development and do not need to
keep any local changes.

Also there can be a situation when remote branch proceeds in a
non-trivial way, e.g. is reset to some historic revision, or is
rebased completely rewriting the history.I think that "git merge"
wouldn't be able to deal with that (as it tries to apply the changes
to local branch, and this local branch can be irrelevant here), but I
expect that "git fetch" + "git reset --hard" will be able to deal with
it.


3. I have never worked with "git submodule" command.
I see that it does not hurt, it is noop for projects that do not use
git modules.

I wonder whether we have a project using this feature.



2016-04-20 22:36 GMT+03:00 William Barker :
> +1 to removing the reset. The idea was to let Gump recover when Git thinks
> the local copy was modifed. But this goes too much against Git's view of
> things. I can't see anything better than the old fashioned rm -rf
>
> On Wednesday, April 20, 2016, Stefan Bodewig  wrote:
>
>> On 2016-04-20, Rainer Jung wrote:
>>
>> > What was the reason for the hard reset and could we remove it until a
>> > better solution is found?
>>
>> I think the reason has been git not picking up the effect of changes to
>> .gitattributes - I'm not convinced the reset helps without removing the
>> index first anyway.
>>
>> Removing the reset is trivial :-)
>>
>> Stefan
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@gump.apache.org 
>> For additional commands, e-mail: general-h...@gump.apache.org
>> 
>>
>>

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

Re: Gump is building stale Checkstyle sources (and other GitHub projects)

[Konstantin Kolinko]

2016-04-18 17:37 GMT+03:00 Konstantin Kolinko <knst.koli...@gmail.com>:
> 2016-04-18 14:15 GMT+03:00 Konstantin Kolinko <knst.koli...@gmail.com>:
>>
>>
>> Maybe there are some other ideas?
>
>
> I looks that my URL theory is wrong.
>
> git clone  git://github.com/checkstyle/checkstyle
>
> completes successfully
>
>
>> E.g. use "git fetch" instead of "git pull",  as we now follow that
>> command with "git reset --hard".
>> I think original plan was "git reset --hard" followed by "git update".
>>
>> Module-level Work  [5]
>>> update_checkstyle
>>> reset_hard_checkstyle
>>> submodule_update_checkstyle
>>
>> [5] http://vmgump.apache.org/gump/public/checkstyle/
>
>
> Looking closer to the above three update/reset/update commands
>
> $ git pull git://github.com/checkstyle/checkstyle master
> From git://github.com/checkstyle/checkstyle
>  * branchmaster -> FETCH_HEAD
> Already up-to-date.
>
> $ git reset --hard origin/master
> HEAD is now at fe17b53 Issue #3000: removed unused check messages
>
> $ git submodule update --init --recursive
>
>
> I am not sure that the first "git pull" command actually updates 
> origin/master.
> If it does not, then resetting to origin/master actually rolls back to
> old sources.
>
> Usually the pull command is just "git pull" without arguments or "git
> pull origin".
>

 is working now, and the results for Checkstyle project are:

http://vmgump.apache.org/gump/public/checkstyle/

1. update_checkstyle

[[[

Command Line

git pull git://github.com/checkstyle/checkstyle master

Output

>From git://github.com/checkstyle/checkstyle
 * branchmaster -> FETCH_HEAD
Updating f9ce38f..d3bafb1
Fast-forward
 src/xdocs/writingjavadocchecks.xml.vm | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

]]]

2. reset_hard_checkstyle

[[[

Command Line

git reset --hard origin/master

Output

HEAD is now at f9ce38f Issue #3105: fixed errors in indentation input files

]]]

3. submodule_update_checkstyle

[[[

Command Line

git submodule update --init --recursive

Output

No output to stdout/stderr from this command.

]]]


Looking at project history on GitHub,
https://github.com/checkstyle/checkstyle/commits/master

f9ce38fba4428b1771dd0e405b450d3b8b46bae3 (f9ce38f)  is a commit from
Apr 18, 2016
d3bafb185b09d28c75ee3d160abe710a43b00d5f (d3bafb1) is a commit from Apr 20, 2016

So "git pull" merged changes between these two commits into current
branch,  then "git reset" resulted in a revert to  f9ce38f, thus
resulting in stale sources.


That "git pull URL branch" command has to be replaced with something else.

Best regards,
Konstantin Kolinko

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

Re: Gump is building stale Checkstyle sources (and other GitHub projects)

[Konstantin Kolinko]

2016-04-18 14:15 GMT+03:00 Konstantin Kolinko <knst.koli...@gmail.com>:
> 2016-04-18 4:40 GMT+03:00 Bill Barker <billbar...@apache.org>:
>> To whom it may engage...
>>
>> This is an automated request, but not an unsolicited one. For
>> more information please visit http://gump.apache.org/nagged.html,
>> and/or contact the folk at general@gump.apache.org.
>>
>> Project tomcat-trunk-validate has an issue affecting its community 
>> integration.
>> This issue affects 1 projects,
>>  and has been outstanding for 2 runs.
>> The current state of this project is 'Failed', with reason 'Build Failed'.
>> For reference only, the following projects are affected by this:
>> - tomcat-trunk-validate :  Tomcat 9.x, a web server implementing the 
>> Java Servlet 4.0,
>> ...
>>
>>
>> Full details are available at:
>> 
>> http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/index.html
>>
>> That said, some information snippets are provided here.
>>
>> The following annotations (debug/informational/warning/error messages) were 
>> provided:
>>  -DEBUG- Dependency on checkstyle exists, no need to add for property 
>> checkstyle.jar.
>>  -INFO- Failed with reason build failed
>>
>>
>>
>> The following work was performed:
>> http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html
>> Work Name: build_tomcat-trunk_tomcat-trunk-validate (Type: Build)
>> Work ended in a state of : Failed
>> Elapsed: 2 secs
>> Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
>> -Dbuild.sysclasspath=only org.apache.tools.ant.Main 
>> -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
>> -Dbase.path=/srv/gump/public/workspace/tomcat-trunk/tomcat-build-libs 
>> -Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar
>>  -Dexecute.validate=true validate
>> [Working Directory: /srv/gump/public/workspace/tomcat-trunk]
>> CLASSPATH: 
>> /usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20160418.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.4-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.5-SNAPSHOT.jar
>>  
>> :/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20160418.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20160418.jar:/srv/gump/public/workspace/google-guava/guava/target/guava-19.0-SNAPSHOT.jar
>> -
>> Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml
>>
>> build-prepare:
>>[delete] Deleting directory 
>> /srv/gump/public/workspace/tomcat-trunk/output/build/temp
>> [mkdir] Created dir: 
>> /srv/gump/public/workspace/tomcat-trunk/output/build/temp
>>
>> compile-prepare:
>>
>> download-validate:
>>
>> testexist:
>>  [echo] Testing  for 
>> /srv/gump/public/workspace/checkstyle/target/checkstyle-5.8-SNAPSHOT.jar
>>
>> setproxy:
>>
>> downloadfile:
>>
>> validate:
>> [mkdir] Created dir: 
>> /srv/gump/public/workspace/tomcat-trunk/output/res/checkstyle
>>
>> BUILD FAILED
>> /srv/gump/public/workspace/tomcat-trunk/build.xml:554: Unable to create a 
>> Checker: Property 'cacheFile' in module Checker does not exist, please check 
>> the documentation
>
>
> Hi!
>
> The above is a build failure of project tomcat-trunk-validate (in
> module tomcat-trunk) [1]
>
> This failure is caused by building a stale version of Checkstyle at Gump.
>
> As can be seen in classpaths above, Gump is building
> checkstyle-5.8-SNAPSHOT.jar,
> but the current version of checkstyle is 6.18-SNAPSHOT (as seen at [2]
> -> pom.xml)
>
> Tomcat configuration for checkstyle uses a 

Gump is building stale Checkstyle sources (and other GitHub projects)

[Konstantin Kolinko]

eckstyle/checkstyle master
]]]

[4] 
http://vmgump.apache.org/gump/public/checkstyle/gump_work/update_checkstyle.html


Comparing it with official pull/clone URL at project site [2] I see
the following concerns

1). The recommended clone URL at [2] is
https://github.com/checkstyle/checkstyle.git

Note it uses "https" protocol and ends the URL with ".git".

2). I wonder why there is no output and no error status.

I guess that we can try running this without the "--quiet" flag.


Searching the project metadata for other projects using
repository="github" there are 11 of them:

Looking at those 11 projects:

checkstyle.xml
http://vmgump.apache.org/gump/public/checkstyle/
https://github.com/checkstyle/checkstyle/
 - stale, builds 5.8-SNAPSHOT. instead of 6.18-SNAPSHOT

easymock.xml
http://vmgump.apache.org/gump/public/easymock/
https://github.com/easymock/easymock
 - build failure

google-guava.xml
http://vmgump.apache.org/gump/public/google-guava/
https://github.com/google/guava/blob/master/pom.xml
- uses ".git" suffix in its URL,
- stale, builds 19.0-SNAPSHOT but current pom.xml is 20.0-SNAPSHOT
I wonder why this one is stale...

java-hamcrest.xml
http://vmgump.apache.org/gump/public/java-hamcrest/
https://github.com/hamcrest/JavaHamcrest

Builds 2.0.0.0 as expected. I cannot confirm staleness.

junit.xml
http://vmgump.apache.org/gump/public/junit/
https://github.com/junit-team/junit4

Builds 4.13-SNAPSHOT as expected. I cannot confirm staleness.

mockito.xml
https://github.com/mockito/mockito
This project is not built by Gump, can be removed.
The project file uses Ant, but the actual project uses Gradle as its
build system (like java-hamcrest above).

objenesis.xml
http://vmgump.apache.org/gump/public/objenesis/
https://github.com/easymock/objenesis/
- stale, builds 2.2-SNAPSHOT, expected is 2.3-SNAPSHOT

openssl.xml
openssl-1.0.2.xml
https://github.com/openssl/openssl/
(branches: master and OpenSSL_1_0_2-stable)
http://vmgump.apache.org/gump/public/openssl-master/
http://vmgump.apache.org/gump/public/openssl-1.0.2/

I cannot confirm staleness here. From build failure emails that I saw
at dev@tomcat I think that these projects are up-to-date.

About twice in a month we see API changes in openssl-master and those
cause build failures in tomcat-native library. So I think that these
projects are up-to-date.

xmlunit.xml
http://vmgump.apache.org/gump/public/xmlunit/
https://github.com/xmlunit/xmlunit/
- Build failure.

xmlunit.net.xml
http://vmgump.apache.org/gump/public/xmlunit.net/
https://github.com/xmlunit/xmlunit.net/
- Build failure.


My plan/proposal is to
1) change repository/github.xml
from git://github.com
to https://github.com

2) add ".git" suffix to all  attributes in projects,

but I wonder of the following


1. What output is suppressed by "--quiet" flag in git pull command.

2. Why google-guava project is stale, while it already uses ".git" suffix.

I expected it to be up-to-date.

Git documentation writes such URLs as ".git/" with trailing "/", but I
doubt that that matters.

3. Whether openssl projects are really up-to-date.

I expect them to be stale.


Maybe there are some other ideas?


E.g. use "git fetch" instead of "git pull",  as we now follow that
command with "git reset --hard".
I think original plan was "git reset --hard" followed by "git update".

Module-level Work  [5]
> update_checkstyle
> reset_hard_checkstyle
> submodule_update_checkstyle

[5] http://vmgump.apache.org/gump/public/checkstyle/

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: r1728404 - /gump/live/python/gump/core/update/git.py

[Konstantin Kolinko]

2016-02-04 5:48 GMT+03:00  <billbar...@apache.org>:
> Author: billbarker
> Date: Thu Feb  4 02:48:13 2016
> New Revision: 1728404
>
> URL: http://svn.apache.org/viewvc?rev=1728404=rev
> Log:
> If somehow the local copy doesn't match we don't care
>
> Modified:
> gump/live/python/gump/core/update/git.py
>
> Modified: gump/live/python/gump/core/update/git.py
> URL: 
> http://svn.apache.org/viewvc/gump/live/python/gump/core/update/git.py?rev=1728404=1728403=1728404=diff
> ==
> --- gump/live/python/gump/core/update/git.py (original)
> +++ gump/live/python/gump/core/update/git.py Thu Feb  4 02:48:13 2016
> @@ -66,6 +66,7 @@ class GitUpdater(ScmUpdater):
>  cmd = Cmd('git', 'update_' + module.getName(),
>module.getSourceControlStagingDirectory())
>  cmd.addParameter('pull')
> +cmd.addParameter('--commit')
>  maybe_make_quiet(module, cmd)
>  cmd.addParameter(module.getScm().getRootUrl())
>  cmd.addParameter(module.getScm().getBranch())

Is Git able to commit if there is no log message provided?

My guess is that it will prepare a message (git fmt-merge-msg) and
launch an editor.
It may be able to detect that it was launched non-interactively (not
sure until we try), but there exists "--no-edit" flag to suppress the
editor.

I wonder why there were local changes to NOTICE.txt file in
commons-lang. There should not have been any.

http://vmgump.apache.org/gump/public/commons-lang-trunk/gump_work/update_commons-lang-trunk.html
[[[
Command Line

git pull --quiet http://git-wip-us.apache.org/repos/asf//commons-lang.git master

Output

error: Your local changes to the following files would be overwritten by merge:
NOTICE.txt
Please, commit your changes or stash them before you can merge.
Aborting
]]]


Personally, I use a script with the following commands to perform a
clean pull from upstream (regardless of current state of my working
copy and the branch I am working on)

git reset --hard
git clean -f -d
git checkout trunk
git pull --rebase

The first two commands
- revert changes in files tracked by git and
- remove untracked files and directories.

There also exists --ff-only flag to git pull, but I never tried it.


Blindly committing with --commit seems wrong unless there is actually
a need to keep local changes. Gump may end with building a different
source tree than contained in the original git repository.

Best regards,
Konstantin Kolinko

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

Re: Projects not listed in main gump.xml file?

[Konstantin Kolinko]

2016-01-16 22:48 GMT+03:00 Dominik Stadler <cen...@apache.org>:
> Hi,
>
> while looking at some failures/warnings of the gump-build, I found that
> quite a list of defined projects is not actually included in the default
> profile/gump.xml file.
>
> Is this on purpose? Some of these are defined at least as optional
> dependencies on some projects...
>
> Thanks... Dominik.
>
>
> $ for i in project/*.xml;do grep -q project/`basename $i` profile/gump.xml
> || echo "Not found: $i"; done
> Not found: project/anakia.xml
> Not found: project/freemarker.xml
> Not found: project/httpcomponents.xml
> Not found: project/jaas.xml
> Not found: project/jena.xml
> Not found: project/jmxremote.xml
> Not found: project/jndi.xml
> Not found: project/jsse.xml
> Not found: project/junit3.xml
> Not found: project/ldap.xml
> Not found: project/mockito.xml
> Not found: project/packaged-bcel.xml
> Not found: project/rhino.xml
> Not found: project/velocity-anakia.xml
> Not found: project/velocity-dvsl.xml
> Not found: project/velocity-engine2.xml
> Not found: project/velocity-engine.xml
> Not found: project/velocity-maven.xml
> Not found: project/velocity-texen.xml
> Not found: project/velocity-tools.xml
> Not found: project/xml-xmlbeans.xml

See svn history of profile/gump.xml
E.g. anakia was removed in this commit:
http://svn.apache.org/viewvc?view=revision=1512820
of 2013-08-10

My guess is that somebody forgot to remove project/anakia.xml (among
~170 files removed in that commit) for some trivial reason, being
confused by something.

(Theoretically one may say that you also need to search other
profiles, though only profile/gump.xml is used by the current running
instance.)

July-August 2013 was when Stefan reached out to other projects asking
whether they find Gump useful and removed a number of unneeded
projects. See the archives.

http://mail-archives.apache.org/mod_mbox/gump-general/201307.mbox/%3C87a9lg77tm.fsf%40v35516.1blu.de%3E

http://mail-archives.apache.org/mod_mbox/gump-general/201308.mbox/%3C87fvuh9yq9.fsf%40v35516.1blu.de%3E

Best regards,
Konstantin Kolinko

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

Re: Board Report Draft

[Konstantin Kolinko]

2015-03-05 17:39 GMT+03:00 Stefan Bodewig bode...@apache.org:
 Hi all

 draft is https://wiki.apache.org/gump/Drafts/BoardReports/20150318 - as
 always, feel free to add, remove or adapt in any other way.


Looks good.

1) Mailing lists statistics, per
https://reporter.apache.org/?gump

(The tool was announced in dev@community.a.o ML, publicly archived at
https://mail-archives.apache.org/mod_mbox/community-dev//201503.mbox/%3C54F591F8.8010305%40apache.org%3E
)

general@gump.apache.org:
Currently: 49 subscribers (down -1 in the last 3 months) (139 emails
sent in the past 3 months, 135 in the previous cycle)

comm...@gump.apache.org:
Currently: 20 subscribers (down -1 in the last 3 months) (142 emails
sent in the past 3 months, 81 in the previous cycle)

2) Regarding Gradle

 Gump has learned to use Gradle to build projects.

Nice work.

It does not have much use currently, though. Essentially it just
verifies that hamcrest trunk builds and tests successfully.  No other
projects depend on binaries produced by the build yet.

http://vmgump.apache.org/gump/public/java-hamcrest/java-hamcrest/details.html

3) Enabled branches support in git element.

It was implemented a long time ago, but it is the first time it is
actually used.

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

4) Reduced the number of daily runs of Gump, from 4 times a day down
to 3 times a day, as duration of a single run is now close to 6 hours.

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: r1661086 - in /gump/live/python/gump: actor/mvnrepoproxy/proxycontrol.py core/build/gradle.py

[Konstantin Kolinko]

2015-02-20 13:52 GMT+03:00  bode...@apache.org:
 Author: bodewig
 Date: Fri Feb 20 10:52:17 2015
 New Revision: 1661086

 URL: http://svn.apache.org/r1661086
 Log:
 take the use latest SNAPSHOT build approach

 Modified:
 gump/live/python/gump/actor/mvnrepoproxy/proxycontrol.py
 gump/live/python/gump/core/build/gradle.py

 Modified: gump/live/python/gump/actor/mvnrepoproxy/proxycontrol.py
 URL: 
 http://svn.apache.org/viewvc/gump/live/python/gump/actor/mvnrepoproxy/proxycontrol.py?rev=1661086r1=1661085r2=1661086view=diff
 ==
 --- gump/live/python/gump/actor/mvnrepoproxy/proxycontrol.py (original)
 +++ gump/live/python/gump/actor/mvnrepoproxy/proxycontrol.py Fri Feb 20 
 10:52:17 2015
 @@ -26,6 +26,21 @@ from gump.core.model.output import OUTPU
  from gump.core.run.actor import AbstractRunActor, FinalizeRunEvent, \
  InitializeRunEvent

 +# list of tuples listing all snapshot repositories we want to mirror
 +#   each tuple consists of a name, the path prefix that identifies the
 +#   repository and the real repository URL without that prefix
 +#   (properly escaped to be used in a Java .properties file).
 +# Since different mvn projects use different names for the same
 +#  repository it is possible to have multiple listings for a single
 +#  repo.  Each name has to be unique as has to be the combination of
 +#  prefix and URL (i.e. each prefix must uniquely map to a real URL)
 +SNAPSHOT_PROXIES = [
 +('apache.snapshots', '/repo/m2-snapshot-repository',
 + 'http\://people.apache.org'),

Is the above repository still useful?

If I go to http://people.apache.org/repo/m2-snapshot-repository/
there is a NOTE text there that says:

Some projects have moved their snapshots to a new repository at
http://repository.apache.org/snapshots. You should update your Maven
builds to use the new repository url since the contents of this
repository is also proxied and aggregated at the new url.



 +('sonatype-nexus-snapshots', '/content/repositories/snapshots',
 + 'https\://oss.sonatype.org')
 +]
 +
  # list of tuples listing all repositories we want to mirror
  #   each tuple consists of a name, the path prefix that identifies the
  #   repository and the real repository URL without that prefix
 @@ -36,12 +51,10 @@ from gump.core.run.actor import Abstract
  #  prefix and URL (i.e. each prefix must uniquely map to a real URL)
  PROXY_CONFIG = [
  ('central', '/maven2', 'http\://repo1.maven.org'),
 -('apache.snapshots', '/repo/m2-snapshot-repository',
 - 'http\://people.apache.org'),
 +SNAPSHOT_PROXIES[0],
  ('maven2-repository.dev.java.net', '/maven/2', 
 'http\://download.java.net'),
  ('m2.dev.java.net', '/maven/2', 'http\://download.java.net'),
 -('sonatype-nexus-snapshots', '/content/repositories/snapshots',
 - 'https\://oss.sonatype.org')
 +SNAPSHOT_PROXIES[1]
  ]

  class MvnRepositoryProxyController(AbstractRunActor):

 ...

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

[Konstantin Kolinko]

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

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

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

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

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

Added in r1659425.

Thank you.

Best regards,
Konstantin Kolinko

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

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

[Konstantin Kolinko]

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

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

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

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

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

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

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

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

Thank you!

Best regards,
Konstantin Kolinko

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

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

[Konstantin Kolinko]

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

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

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

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

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

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

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

 Did you mean APR here?

Fixed. Thank you!

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

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


Best regards,
Konstantin Kolinko

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

Change metadata external at Gump live to use relative URL

[Konstantin Kolinko]

Hi!

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

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

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

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

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


Best regards,
Konstantin Kolinko

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

Gump is not running since end of October

[Konstantin Kolinko]

Hi!

Apparently the last run of Gump was on October 29th.
http://vmgump.apache.org/gump/public/

Is it a missing cron task, or there is some more serious issue?

Best regards,
Konstantin Kolinko

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

Re: logging-log4j-12 failed

[Konstantin Kolinko]

2013/10/15 Stefan Bodewig bode...@apache.org:
 On 2013-10-15, Ludmila Shikhvarg wrote:

 Stefan Bodewig wrote:
 On 2013-10-07, Ludmila Shikhvarg wrote:


 Hi,



 I'm using JDK8 from https://jdk8.java.net/download.html to run gump.
 logging-log4j-12 is started to fail with b75 and onward (the build log
 is attached).
 Any ideas?



 com.sun.tools.javac.code.Symbol$CompletionFailure: class file for 
 sun.util.locale.provider.LocaleProviderAdapter not found
 com.sun.tools.doclets.internal.toolkit.util.DocletAbortException: 
 com.sun.tools.javac.code.Symbol$CompletionFailure: class file for 
 sun.util.locale.provider.LocaleProviderAdapter not found


 Looks like a defect in javadoc to me - at least not like anything the
 log4j devs would be able to fix.

 Stefan

 The same exception seen before the failure.
 Heads up:
 javadoc -Xdoclint is a new feature in jdk8. Default behavior is on so
 that javadoc now issues warnings and errors and problems in javadoc
 comments in the source:

 $ jdk8/bin/javadoc -X
  -XdoclintEnable recommended checks for
 problems in javadoc comments
  -Xdoclint:(all|none|[-]group)
Enable or disable specific checks for problems in javadoc comments,
   where group is one of accessibility, html, missing, reference,
 or syntax.

 You may choose to fix your javadoc comments, or to get backward
 compatible behavior with jdk7 use -Xdoclint:none.

 I'll forward this to the log4j developers.  But I really don't think
 this is an option.  This is Java6:

 ,
 | $ javadoc -Xdoclint:none
 | javadoc: error - invalid flag: -Xdoclint:none
 `

 so my build process would have to detect Java8 at runtime and pass
 different arguments to javadoc based on it - this adds complexity.

 TBH I think it is a really bad idea to change defaults in a manner that
 breaks the build processes of code that worked before.

 In addition the exception itself isn't really helpful as it doesn't say
 what is wrong (at least I didn't see anything) but rather looks like a
 bug in javadoc - that one can avoid to trigger.



Release notes for recently released JDK 7u45 mention that it fixes
several security issues in the Javadoc tool: CVE-2013-5797,
CVE-2013-5804 [1]

It seems that general concern is that generated HTML may contain
script code insertions. A logical extension to this would be that at
some point Javadoc could become more strict on what HTML it processes.
It might be what is currently happening with JDK8. (Just my guess).

Besides usual warnings, the log attached to the first e-mail lists a
number of HTML errors in those Javadoc comments, such as

AsyncAppender.java:37: error: self-closing element not allowed
 * p/
   ^

EnhancedPatternLayout.java:86: error: tag not allowed here: th
   thConversion Character/th
   ^

XMLLayout.java:47: error: invalid entity data;
  nbsp;nbsp;data;

An exception among those errors (Symbol$CompletionFailure: class file
for sun.util.locale.provider.LocaleProviderAdapter not found)  should
be a bug in the Javadoc tool itself, but it seems non-fatal, as other
errors are reported after that.

From names of methods in the stack trace I guess that the error
occurred when generating class summary part of some HTML page. I guess
that page may be missing from generated Javadoc.


[1] 
http://www.oracle.com/technetwork/topics/security/cpuoct2013verbose-1899842.html#JAVA

(If anyone is interested, details on those issues fixed in JDK 7u45
are not yet available from Oracle or MITRE, but they can be found in
RedHat bugzilla,

https://access.redhat.com/security/cve/CVE-2013-5797
https://bugzilla.redhat.com/show_bug.cgi?id=1018720
https://access.redhat.com/security/cve/CVE-2013-5804
https://bugzilla.redhat.com/show_bug.cgi?id=1019131
)

Best regards,
Konstantin Kolinko

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

Re: [GUMP@vmgump]: Project tomcat-tc7.0.x-validate (in module tomcat-7.0.x) failed

[Konstantin Kolinko]

2013/8/20 Mark Thomas ma...@apache.org:
 On 20/08/2013 00:50, Bill Barker wrote:

 snip/

 validate:
 [mkdir] Created dir: 
 /srv/gump/public/workspace/tomcat-7.0.x/output/res/checkstyle
 [checkstyle] Running Checkstyle 5.7-SNAPSHOT on 2388 files
 [checkstyle] 
 /srv/gump/public/workspace/tomcat-7.0.x/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/DefaultTestCase.java:22:1:
  Import from illegal package - junit.framework.TestCase.
 [checkstyle] 
 /srv/gump/public/workspace/tomcat-7.0.x/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/TestAsyncQueue.java:24:1:
  Import from illegal package - junit.framework.TestCase.
 [checkstyle] 
 /srv/gump/public/workspace/tomcat-7.0.x/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/TestSizePreservation.java:22:1:
  Import from illegal package - junit.framework.TestCase.

 BUILD FAILED
 /srv/gump/public/workspace/tomcat-7.0.x/build.xml:451: Got 3 errors and 0 
 warnings.

 Gump doesn't appear to be using the latest source code for this build.
 As far as I can tell, the project is set up so it should use the latest
 source from svn. What am I missing?


1)
 First, model-level log

http://vmgump.apache.org/gump/public/tomcat-7.0.x/index.html
says
 *** Failed to update from source control.Stale contents ***

and the following:
[[[
svn: URL 'http://svn.apache.org/repos/asf/tomcat/trunk/modules/jdbc-pool'
of exis...
ting directory 'tomcat-7.0.x/modules/jdbc-pool' does not match
expected URL 'htt...
p://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/modules/jdbc-pool'
]]]

I think removing the whole directory and performing a clean svn
checkout should fix this.


(The modules/jdbc-pool directory was an external that pulled sources
from Tomcat trunk,
but nowadays it is just an ordinary subdirectory. This change happened
more than a year ago. I think most of the sources in the working copy
are up-to-date, but that particular directory is stale. It explains
why it went unnoticed for quite some time).

2)
 Second,  I suspect that svn update happens when a Gump run starts.
That may be several hours before the actual build. I do not see any
indication of what revision number was used for the build.

Is it possible to remove --quiet flag from svn update command?
With that flag removed it would print
a) list of updated files,
b) svn revision number to which the working copy was updated.

http://vmgump.apache.org/gump/public/tomcat-7.0.x/gump_work/update_tomcat-7.0.x.html


Best regards,
Konstantin Kolinko

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

Re: [GUMP@vmgump]: Project tomcat-taglibs-standard (in module tomcat-taglibs) failed

[Konstantin Kolinko]

2012/11/28 Henri Yandell flame...@gmail.com:
 Sorry for cluelessness on my part, but I'm wondering what the best way
 is to turn this off/fix this? Afaict the issue is because Gump is
 building with a newer version of Java than that which JSTL is designed
 for.

 Hen

 [Not on the list, so please keep me cc'd]


My somewhat naive thought is that maybe declare it to be dependent on
commons-dbcp project.  When precondition fails the project is not
built, but the good side is that it does not send the nagging e-mails.

Such dependency is currently the cause why Tomcat trunk, 7, 6
currently do not build, e.g.:
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-dbcp/

(My plan is to resolve the issue in Tomcat is to stop building its
dbcp component and remove dependencies on it. I do not have time for
this at the moment, though.)

Note that FreeBSD and MacOS hosts do build taglibs successfully:

http://gump.zones.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/
http://adam.apache.org/gump/tomcat-taglibs/tomcat-taglibs-standard/

Best regards,
Konstantin Kolinko

 -- Forwarded message --
 From: Gump bay...@apache.org
 Date: Tue, Nov 27, 2012 at 11:56 PM
 Subject: [GUMP@vmgump]: Project tomcat-taglibs-standard (in module
 tomcat-taglibs) failed
 To: d...@tomcat.apache.org


 To whom it may engage...

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

 Project tomcat-taglibs-standard has an issue affecting its community
 integration.
 This issue affects 2 projects,
  and has been outstanding for 210 runs.
 The current state of this project is 'Failed', with reason 'Build Failed'.
 For reference only, the following projects are affected by this:
 - tomcat-taglibs-standard :  Standard Taglib
 - tomcat-taglibs-standard-install :  JSP Taglibs


 Full details are available at:
 
 http://vmgump.apache.org/gump/public/tomcat-taglibs/tomcat-taglibs-standard/index.html

 (...)
 [ERROR] 
 /srv/gump/public/workspace/tomcat-taglibs/standard/impl/src/main/java/org/apache/taglibs/standard/tag/common/sql/DataSourceWrapper.java:[38,7]
 error: DataSourceWrapper is not abstract and does not override
 abstract method getParentLogger() in CommonDataSource
 [INFO] 1 error
 [INFO] -
 [INFO] 
 
 [ERROR] BUILD FAILURE

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

Re: Tightening up our Wiki

[Konstantin Kolinko]

2012/5/4 Stefan Bodewig bode...@apache.org:
 Hi all,

 the user wikimouse is using new techniques that makes it more difficult
 to keep spam out of the Wiki: he reverts the pages to those that
 contained spam once we delete it - this does not send out notification
 mails - and uses tinyurl to circumvent the BadContent list.

 I suggest we close down Wiki access to the few of us who actually edit
 the Wiki from time to time using
 http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot

 I'll ask infra to change the setup in a few days unless anybody stops
 me.


Add tinyurl.com to the list of spam addresses? We did so in Tomcat a year ago,
http://wiki.apache.org/tomcat/LocalBadContent

 Still, in Gump's case there only are very few people who ever edit the
 Wiki so the ContributorGroup setup would be a good fit IMHO.

I agree.

Best regards,
Konstantin Kolinko

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

Re: Resolving reference to commons-io-*[0-9T].jar file in a property

[Konstantin Kolinko]

cc'ing dev@tomcat.

It is about dependency on  commons-io-*[0-9T].jar that caused
jakarta-tomcat-catalina (aka Tomcat 5.5) build on Gump to fail.


2012/4/20 Stefan Bodewig bode...@apache.org:
 On 2012-04-20, Bill Barker wrote:

 This should be in the next Gump run on vmgump that will start at about
 12am GMT. This should fix the older Tomcat projects that want to copy
 jars from other projects with glob names in the target project.

 Great.


Thank you, Bill!
The recent build [1] completed successfully.

[1] 
http://vmgump.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html

 I could try and fix other Builders, but except for Ant, they don't
 generally set properties on individual jar/output files that are
 globbed.

 Let's leave it at that and patch the remaining builders once we need it.


Now that this feature works, I'll update tomcat-tc7.0.x-validate
target on Gump today
and will do the same for tomcat-trunk-validate tomorrow,
to remove hard-coded checkstyle version number there.

Just warning dev@ in advance in case it breaks.

Best regards,
Konstantin Kolinko

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

Resolving reference to commons-io-*[0-9T].jar file in a property

[Konstantin Kolinko]

Hi!

It is essentially the same issue that I wrote about a year ago, [1]

Now it is occurring in jakarta-tomcat-catalina project [2]. It
started to nagging dev@tomcat on April 12th, but I do not see what
could cause it. I guess that earlier it did not run due to some
dependency. Another change is that commons-io 2.3 was released about
that time.


The problem: When Tomcat 5.5 builds it needs to copy commons-io.jar
into its Manager webapp. There is the following code in its Ant
file:

/tomcat/tc5.5.x/trunk/container/webapps/manager/build.xml
[[[
  target name=copy-io.jar
copy todir=${webapps.build}/${webapp.name}/WEB-INF/lib
file=${commons-io.jar}/
  /target
]]]

In Gump this is configured in project/jakarta-tomcat-catalina.xml as
ant ...
  depend property=commons-io.jar project=commons-io /
/ant

It results in
[[[
BUILD FAILED
/srv/gump/public/workspace/jakarta-tomcat-catalina/build.xml:74: The
following error occurred while executing this line:
/srv/gump/public/workspace/jakarta-tomcat-catalina/webapps/build.xml:58:
The following error occurred while executing this line:
/srv/gump/public/workspace/jakarta-tomcat-catalina/webapps/manager/build.xml:56:
Warning: Could not find file
/srv/gump/public/workspace/apache-commons/io/target/commons-io-*[0-9T].jar
to copy.
]]]

The actual name of the file is commons-io-2.4-SNAPSHOT.jar [3]

Should I change the dependency to explicitly name the file? Like this:

  property name=commons-io.jar project=commons-io
path=io/target/commons-io-2.4-SNAPSHOT.jar /

or there is a chance to make those patterns to work?


[1] Dependency on checkstyle.jar in tomcat-trunk-validate returns
glob instead of actual name, 2011-04
http://markmail.org/message/to3dvdwwciqzgrgh

[2] jakarta-tomcat-catalina project summary
http://vmgump.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html

[3] apache-commons/commons-io Build output
http://vmgump.apache.org/gump/public/apache-commons/commons-io/gump_work/build_apache-commons_commons-io.html

Best regards,
Konstantin Kolinko

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

Re: xml-commons RIP

[Konstantin Kolinko]

2012/4/15 Bill Barker billwbar...@verizon.net:
 It seems that xml-commons' repository has gone away.  I found this out while
 testing a local version of Gump that had no checkouts. Given that it is
 stale, and in the boot-classpath of just about every ant project, it should
 go away for modern JVMs.  I just want opinions on options. As I see it the
 choices are:

 1) leave the stale projects, but remove the boot attribute. Upside, least
 amount of work. Downside, nobody will be able to set up a fresh Gump.
 2) make the projects empty, and think of something for the couple of
 projects that have a property .../ depend (or just let them fail).
 3) remove it completely and edit a large number of projects that refer to it
 4) Ignore the problem completely until there is a break with the JVM.

 My personal preference is in order 2,1,4,3, but want to hear other opinions
 first.


I did not find it in ASF Attic so I went on looking into svn log. So I see that
it was moved into /xerces/xml-commons:

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

http://svn.apache.org/viewvc/xerces/xml-commons/trunk/


About the above list of options :
I do not understand what you meant by 2). You clear the metadata file
of that module? Or you meant start over with empty list of modules in
profile/gump.xml?

Regarding 3) the only projects that explicitly refer to xml-commons
are ant, ant-1.8.x, xml-xerces2. That is not much. The rest should be
an indirect dependency. I wonder whether Ant really needs it.

When dealing with svn repositories it is also possible to 5) freeze
them in time by setting certain peg and operative revisions. I do not
know whether Gump supports that (as it defeats its purpose), but it
might be doable.

If those repository paths are passed to command-line client as is,
this syntax might be already working:

  svn repository=asf dir=xml/commons/trunk@1311707/

I am not doing any updates to the metadata now - I think you would
better try on a standalone Gump that you have, because so many
projects depend on it.

Best regards,
Konstantin Kolinko

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

Re: Problem with mercurial 2.1

[Konstantin Kolinko]

2012/3/28 Stefan Bodewig bode...@apache.org:
 On 2012-03-18, Konstantin Kolinko wrote:

 2012/3/16 Stefan Bodewig bode...@apache.org:
 Hi,

 maybe somebody with more experience with hg than myself can help.

 With the upgrade of the the FreeBSD jail gump is now using Mercurial 2.1
 there.  Since them most if not all hg updates are failing.  The reason
 is (quoting hg help pull)

 ,
 |     Returns 0 on success, 1 if no changes found or an update had 
 unresolved
 |     files.
 `

 so Gump can no longer tell a pull that didn't change anything from one
 that failed (I'm sure there is an explanation why mixing nothing to do
 with things have failed is not silly).

 Searching about this issue, I see that people say that the old
 behaviour was restored in Mercurial 2.1.1 (released 2012-03-01).

 Thanks, I didn't search myself.

 (...)
 I don't have any idea if/when FreeBSD may update hg.


Just searching Ports catalog at freebsd.org,
http://www.freebsd.org/cgi/ports.cgi?query=^mercurial-2.1.1stype=name

shows that 2.1.1 does exist and apparently was released just today (March 28).

(Well, I do not know much about FreeBSD, so no clue whether this can
be used as is, or how long you'd have to wait.  Just some good news).

Best regards,
Konstantin Kolinko

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

Re: Problem with mercurial 2.1

[Konstantin Kolinko]

2012/3/16 Stefan Bodewig bode...@apache.org:
 Hi,

 maybe somebody with more experience with hg than myself can help.

 With the upgrade of the the FreeBSD jail gump is now using Mercurial 2.1
 there.  Since them most if not all hg updates are failing.  The reason
 is (quoting hg help pull)

 ,
 |     Returns 0 on success, 1 if no changes found or an update had unresolved
 |     files.
 `

 so Gump can no longer tell a pull that didn't change anything from one
 that failed (I'm sure there is an explanation why mixing nothing to do
 with things have failed is not silly).


Searching about this issue, I see that people say that the old
behaviour was restored in Mercurial 2.1.1 (released 2012-03-01).

[1] 
http://stackoverflow.com/questions/9410140/mercurial-2-1-how-can-i-use-pull-incoming-without-getting-return-code-1-when-th
[2] http://mercurial.selenic.com/wiki/UpgradeNotes
[3] http://selenic.com/pipermail/mercurial-devel/2012-February/037986.html



 Does anybody see any way to make hg support work without making it a
 two-step process of running hg incoming first and only run pull if
 that returned 0?


Maybe wrap hg pull with some script and examine what last line of
its output says. People say that it is localized, but you can know
what language your FreeBSD instance uses.  Or just ignore the return
code for now - until you can install 2.1.1.

Best regards,
Konstantin Kolinko

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

Re: Fix expat-configure build failures on Gump

[Konstantin Kolinko]

2012/2/24 Stefan Bodewig bode...@apache.org:
 On 2012-02-21, Stefan Bodewig wrote:

 On 2012-02-17, Konstantin Kolinko wrote:

 b.  use system-provided version of expat

 Unless anybody can provide more information on the autoreconf solution
 this might be the only way to go.  Can't promise when I'll find time to
 look into it, though.

 The current run on vmgump is using a system provided expat and APR has
 been built successfully.


Thank you! It is good news.

Best regards,
Konstantin Kolinko

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

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

[Konstantin Kolinko (Commented) (JIRA)]

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

Konstantin Kolinko commented on GUMP-153:
-

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

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

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

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

 Gump Metadata: links no longer work
 ---

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

 The Gump meta data links no longer work, now that the metadata is in SVN.
 For example:
 http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-jmeter.xml
 should now be:
 http://svn.apache.org/repos/asf/gump/metadata/project/jakarta-jmeter.xml
 However, it would be better if the meta data link pointed to the actual file 
 used by Gump for that run, rather than the current SVN contents, as that may 
 have been updated since the run.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (GUMP-116) Promote using html in description/ fields

[Konstantin Kolinko (Commented) (JIRA)]

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

Konstantin Kolinko commented on GUMP-116:
-

I think it is not needed.
There is url element in a module [1] that links to the official web site of a 
project.
That should be enough, because the official site is the authoritative source of 
information on a project. The site is always maintained better than Gump 
metadata.

[1] http://gump.apache.org/metadata/module.html#url

 Promote using html in description/ fields
 ---

 Key: GUMP-116
 URL: https://issues.apache.org/jira/browse/GUMP-116
 Project: Gump
  Issue Type: Improvement
  Components: Object Model (GOM)
Affects Versions: GOM-0.5
Reporter: Leo Simons
 Fix For: GOM-0.5


 It would be cool if description/ fields contained more useful content. For 
 example, it might make sense to provide links to a wiki page with developer 
 information about debugging a particular project, or links to additional 
 build functionality a project utilizes outside of gump (like nightly build 
 download locations). This would mean the description/ content should get a 
 prominent place in gump-generated docs, the GOM docs are updated to detail 
 that one can, in fact, use HTML, and that we promote the practice in some way.
 Thinking of maven POMs, their description/ and longDescription/ contents 
 might need to be extended to have that kind of information relevant for 
 developers. One could have a developerInfo/ in addition to those, I dunno. 
 Maybe the maven people have something plannen already :-D

--
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-147) Complain if a project does not provide all the outputs it states

[Konstantin Kolinko (Commented) (JIRA)]

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

Konstantin Kolinko commented on GUMP-147:
-

I think it is already implemented.
The lucene-java project recently had the issue of missing outputs and that 
caused the project to be marked as failed. So this check is working.

Notification email contains [1] (search for lucene-java):
[[[
The current state of this project is 'Failed', with reason 'Missing Build 
Outputs'.
]]]

The issue in lucene-java was [2] that their build configuration was changed and 
jars were produced in a different place. The built was successful (and link to 
build output was green), but the whole project was in the failed state.  So 
this check actually works.

I do not know whether the check iterates over all outputs, as lucene-java 
project has only one jar.

For reference:
[1] http://marc.info/?l=gumpm=132938480323353w=2
[2] http://svn.apache.org/viewvc?view=revisionrevision=1290917

 Complain if a project does not provide all the outputs it states
 

 Key: GUMP-147
 URL: https://issues.apache.org/jira/browse/GUMP-147
 Project: Gump
  Issue Type: New Feature
  Components: Python-based Gump
Affects Versions: Gump3-alpha-7
Reporter: Leo Simons
 Fix For: Gump3-alpha-7


 We should have a post-processing plugin (maybe one-per-output-type) that 
 looks for successfully built projects, then goes and peeks if each and every 
 of the outputs it specifies now actually exists (probably os.exists() and 
 sometimes os.isfile() and os.isdir() if appropriate). If not, the plugin 
 should mark the failure on the output.
 The logreporter should be modified to include this information with each 
 project (this is probably a METADATA FAILURE), eg loop over all outputs for 
 all projects and check_failure on each of them.

--
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-155) Gump complains that the HiveMind build failed, when it does not

[Konstantin Kolinko (Commented) (JIRA)]

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

Konstantin Kolinko commented on GUMP-155:
-

This 7 year old issue is already answered. It was configuration issue in a 
project, not a Gump bug.
It is time to close it.

BTW, hivemind is not built by Gump nowadays.

 Gump complains that the HiveMind build failed, when it does not
 ---

 Key: GUMP-155
 URL: https://issues.apache.org/jira/browse/GUMP-155
 Project: Gump
  Issue Type: Bug
Reporter: Howard M. Lewis Ship

 I get emails from Gump all the time that claim there's an error, but there's 
 no indication of what the error is (notice that all the tests passed):
 To whom it may engage...
 This is an automated request, but not an unsolicited one. For
 more information please visit http://gump.apache.org/nagged.html,
 and/or contact the folk at general@gump.apache.org.
 Project jakarta-hivemind has an issue affecting its community integration.
 This issue affects 3 projects,
  and has been outstanding for 61 runs.
 The current state of this project is 'Failed', with reason 'Build Failed'.
 For reference only, the following projects are affected by this:
- jakarta-hivemind :  HiveMind is a services and configuration
microkernel
- jakarta-hivemind-library :  HiveMind is a services and configuration
microkernel
- jakarta-tapestry :  Component-based web application framework organized 
 around i...
 Full details are available at:

 http://vmgump.apache.org/gump/public/jakarta-hivemind/jakarta-hivemind/index.html
 That said, some information snippets are provided here.
 The following annotations (debug/informational/warning/error messages) were 
 provided:
  -DEBUG- Sole output [hivemind-28092005.jar] identifier set to project name
  -INFO- Failed with reason build failed
  -INFO- Failed to extract fallback artifacts from Gump Repository
 The following work was performed:
 http://vmgump.apache.org/gump/public/jakarta-hivemind/jakarta-hivemind/gump_work/build_jakarta-hivemind_jakarta-hivemind.html
 Work Name: build_jakarta-hivemind_jakarta-hivemind (Type: Build)
 Work ended in a state of : Failed
 Elapsed: 42 secs
 Command Line: java -Djava.awt.headless=true -Dant.build.clonevm=true 
 -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
  org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
 -Dbuild.sysclasspath=only -Djava.classes.dir=target/classes 
 -Djunit-available=true -Djavacc.home=/usr/local/gump/packages/javacc-3.1 
 -Ddownload-warning-marker-displayed=true 
 -Dtest.classes.dir=target/test-classes -Dproject.version=28092005
 [Working Directory: 
 /usr/local/gump/public/workspace/jakarta-hivemind/framework]
 CLASSPATH: 
 /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-hivemind/hivebuild/target/classes:/usr/local/gump/public/workspace/jakarta-hivemind/framework/target/classes:/usr/local/gump/public/workspace/jakarta-hivemind/framework/target/test-classes:/usr/local/gump/public/workspace/jakarta-hivemind/framework/src/descriptor:/usr/local/gump/public/workspace/jakarta-hivemind/framework/src/test:/usr/local/gump/public/workspace/jakarta-hivemind/framework/src/test-data:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-28092005.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api-28092005.jar:/usr/local/gump/packages/easymock1.2_Java1.3/easymock.jar:/usr/local/gump/packages/easymockclassextension1.2/easymockclassextension.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-28092005.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/javacc-3.1/bin/lib/javacc.jar:/usr/local/gump/public/workspace/javassist/javassist.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/logging-log4j/log4j-28092005.jar:/usr/local/gump/public/workspace/asm/output/dist/lib/asm-analysis-28092005.jar:/usr/local/gump/public/workspace/asm/output/dist/lib/asm-attrs-28092005.jar:/usr/local/gump/public/workspace/asm/output/dist/lib/asm-util-28092005.jar:/usr/local/gump/public/workspace

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

[Konstantin Kolinko (Commented) (JIRA)]

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

Konstantin Kolinko commented on GUMP-161:
-

See my comment to GUMP-153

 Apache Gump Metadata does not show actual version used
 --

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

 The Apache Gump Metadata link points to SVN. As such, it may show a more 
 recent version than was actually used.
 It would be helpful to show the actual metadata file, either in the 
 workspace, or by including the SVN revision of the file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Modules using Git cannot update themselves on vmgump

[Konstantin Kolinko]

Hi!

There are totally 8 modules that use Git as their repository type.

As of now on vmgump all of them fail to update their sources and thus
are building from stale content. The error
in all cases is the following:
[[[
Command Line

git pull --quiet git://github.com/KentBeck/junit

Output

You asked to pull from the remote 'git://github.com/KentBeck/junit',
but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
]]]

Here are repository references from all those modules:

1 git repository=github dir=/kohsuke/args4j.git/
2 git repository=github dir=/belaban/JGroups.git/
3 git repository=jline/
4 git repository=github dir=/KentBeck/junit/
5 git repository=github dir=/kohsuke/msv.git/
6 git repository=github dir=/nant/nant.git/
7 git repository=github dir=/ceki/slf4j.git/
8 git repository=xz-java/

Here are links to their update work results on vmgump:

1 http://vmgump.apache.org/gump/public/args4j/gump_work/update_args4j.html
2 http://vmgump.apache.org/gump/public/jgroups/gump_work/update_jgroups.html
3 http://vmgump.apache.org/gump/public/jline/gump_work/update_jline.html
4 http://vmgump.apache.org/gump/public/junit/gump_work/update_junit.html
5 http://vmgump.apache.org/gump/public/msv/gump_work/update_msv.html
6 http://vmgump.apache.org/gump/public/nant/gump_work/update_nant.html
7 http://vmgump.apache.org/gump/public/slf4j/gump_work/update_slf4j.html
8 http://vmgump.apache.org/gump/public/xz-java/gump_work/update_xz-java.html

This issue is specific to vmgump server. The two other servers do not
have this issue.
Here are links for junit module:
4 http://gump.zones.apache.org/gump/public/junit/gump_work/update_junit.html
4 http://adam.apache.org/gump/junit/gump_work/update_junit.html


Looking at gump_work/check_git.html pages all servers use different
versions of git.
vmgump:  git version 1.7.0.4
gump.zones: git version 1.7.6
adam: git version 1.7.9

So vmgump uses the oldest one.

Best regards,
Konstantin Kolinko

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

Fix expat-configure build failures on Gump

[Konstantin Kolinko]

Hi!

I would like to make use of Tomcat native connectors built by
tomcat-connectors-native module. The problem is that this module
cannot be built because of prerequisites failure. The project depends
on httpd - apr - expat, and expat-configure is failing. It is in the
failed state for very long time.

Previous discussion that I found, from August 2010 expat-configure
problem [1], says that the problem is that the build is incompatible
with new version of autoconf.

That thread mentions that some servers were building expat
successfully at that time. But nowadays all Gump servers that I know
about are failing this build (vmgump, freebsd, Mac OS X (adam)). E.g.
[2]

[1] http://marc.info/?t=128146620400019r=1w=2
[2] http://vmgump.apache.org/gump/public/expat/expat-configure/
http://adam.apache.org/gump/expat/expat-configure/
http://gump.zones.apache.org/gump/public/expat/expat-configure/

Is it possible to fix this issue?

I see that [1] mentions two possible workarounds
a.  apply some fix
b.  use system-provided version of expat



Best regards,
Konstantin Kolinko

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

Re: Delete stale files in tomcat-trunk workspace

[Konstantin Kolinko]

2012/1/21 Stefan Bodewig bode...@apache.org:
 On 2012-01-20, Konstantin Kolinko wrote:

 Can someone delete the following folder at vmgump, note the double
 jdbc-pool/jdbc-pool ?

  /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/jdbc-pool/

 I've deleted the whole working copy of tomcat-trunk which should make
 Gump create a fresh checkout and purge everything from the workspace
 when it syncs on the next Gump run.

 Also done for the FreeBSD jail.


Thank you!
Confirming that the issue is resolved. The recent build has been successful.

Best regards,
Konstantin Kolinko

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

Delete stale files in tomcat-trunk workspace

[Konstantin Kolinko]

Hi!

Can someone delete the following folder at vmgump, note the double
jdbc-pool/jdbc-pool ?

 /srv/gump/public/workspace/tomcat-trunk/modules/jdbc-pool/jdbc-pool/


The modules/jdbc-pool is a valid folder from source three [1], but
second nested modules/jdbc-pool/jdbc-pool is a wrong one.

[1] http://svn.apache.org/viewvc/tomcat/trunk/modules/


I reckon that someone was experimenting with svn:externals property on
one of those folders, and so I suppose that this wrong jdbc-pool is
a nested svn Working copy created from such external. It is known
issue that svn 1.6 clients are not able to remove such nested WCs when
external is removed.

This problem was unnoticed, but two days ago I enabled checkstyle
checks for that module. Those stale sources cause failure of
tomcat-trunk-validate build [2].

[2] 
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html

Best regards,
Konstantin Kolinko

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

Dependency on checkstyle.jar in tomcat-trunk-validate returns glob instead of actual name

[Konstantin Kolinko]

Hi!

I am trying to troubleshoot the build of tomcat-trunk-validate
project, which currently fails.

Project metadata:
[1] http://svn.apache.org/repos/asf/gump/metadata/project/tomcat-trunk.xml

To successfully run the build, the full path to checkstyle.jar is needed.

The problem is that instead of the actual path to the jar file, the
build script gets what is
written in checkstyle project metadata: a glob pattern of the name.


The build fails: Build output, from [2]:
[[[
testexist:
 [echo] Testing  for
/srv/gump/public/workspace/checkstyle/target/checkstyle-*[0-9T].jar

downloadzip:
  [get] Getting:
http://downloads.sourceforge.net/checkstyle/checkstyle-5.3-bin.zip
  [get] To: /usr/share/java/file.zip
]]]

[2] 
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate/gump_work/build_tomcat-trunk_tomcat-trunk-validate.html

The testexists target of the build file fails and the build goes on
trying to download the file (which it should not do).

[[[
  target name=testexist
echo message=Testing  for ${destfile}/
available file=${destfile} property=exist/
  /target
]]]


The dependency is specified as follows [1]:
[[[
 project name=tomcat-trunk-validate
(...)
   ant target=validate
  depend property=checkstyle.jar project=checkstyle/
  (...)
   /ant
(...)
  /project
]]]

Another project, tomcat-trunk-test in [1] uses
[[[
  property name=checkstyle.jar project=checkstyle
 reference=jarpath /
]]]
but it does not make any difference it resolves to the same
(...)/checkstyle-*[0-9T].jar pattern, as can be seen in [3].

[3] 
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/details.html


According to the build output of checkstyle project [4], the actual
name should be:
/srv/gump/public/workspace/checkstyle/target/checkstyle-5.3-SNAPSHOT.jar

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


Why depend property=checkstyle.jar project=checkstyle/ in an
ant builder does
not resolve to the full path to the actual jar file, but glob pattern
is returned instead?

Is there a way to get the actual name of the jar file?


Best regards,
Konstantin Kolinko

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