RE: new dependency
Hi Martin, Martin Gainty wrote: Luis personally i never download snapshots as snapshots reflect the collection of files at a particular date/time Well, but that's the whole purpose of Gump. Even more, Gump will take a SNAPSHOT anyway - unless you overwrite this in the Gump descriptor, see Stefan's answer. [snip] - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Tightening up our Wiki
Hi, Stefan Bodewig wrote: 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. Hmm. Why not have a general security setting to allow reverts only for privileged people (i.e. those who can edit BadContent)? Tinyurls: Do we really need those in the wiki? The URL is normally hidden in the markup anyway and it does then not matter how long it is. - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: xml-apis fails
Hi Sebb, sebb wrote: On 9 December 2010 05:33, Stefan Bodewig bode...@apache.org wrote: On 2010-12-09, Ludmila Shikhvarg wrote: Use windows 7 with cygwin environment to run gump, I don't think anybody has ever tried to run Gump on Windows and I'm very sure there are a few unixisms inside the code. It's probably fair to assume it simply won't work and Gump requires a Unix-like system with Unix conventions for paths and filenames. In particular java must use Unix like conventions. Not sure that's true. In this case it is. Command Line c:/jdk1.6.0_21/bin/java -Xbootclasspath/p:/home/dtftest/gump/packages/jaxp-1_3/jaxp- api.jar:/home/dtftest/gump/packages/jaxp-1_3/dom.jar:/home/dtftest/gump/packages/jaxp-1_3/sax.jar:/home/dtftest/gump/packages/jaxp-1_3/xercesImpl.jar:/home/dtftest/gump/packages/jaxp-1_3/xalan.jar org.apache.tools.ant.Main -Dgump.merge=/home/dtftest/gump/work/merge.xml There should be a space or = after -Xbootclasspath - that might explain the the problem? The path still uses ':' as separator and some added paths start with /home/xxx which are typically Cygwin paths. Both cannot be processed by a Windows-based java. The bootclasspath is not a Windows path, this likely won't work at all. Therefore Stefan is right. However, it seems that it's not a Java application that creates those constructs, but some Unix shell scripts. If the original poster can adjust those to provide real Windows paths when invoking Java, he might get Gump running. Stefan might be interested in patches in that case ;-) - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: xml-apis fails
Hi Stefan, Stefan Bodewig wrote: On 2010-12-09, Jörg Schaible wrote: Command Line c:/jdk1.6.0_21/bin/java -Xbootclasspath/p:/home/dtftest/gump/packages/jaxp-1_3/jaxp- api.jar:/home/dtftest/gump/packages/jaxp-1_3/dom.jar:/home/dtftest/gump/packages/jaxp-1_3/sax.jar:/home/dtftest/gump/packages/jaxp-1_3/xercesImpl.jar:/home/dtftest/gump/packages/jaxp-1_3/xalan.jar org.apache.tools.ant.Main -Dgump.merge=/home/dtftest/gump/work/merge.xml There should be a space or = after -Xbootclasspath - that might explain the the problem? No, the syntax is -Xbootcpasspath/p:PATH - see java -X. The path still uses ':' as separator which is puzzling since it is generated by a Path instance that runs through the getFlattened method at the bottom of http://svn.apache.org/repos/asf/gump/trunk/python/gump/core/language/path.py which uses os.pathsep Could this be a cygwin aware version of Python that is too much aware of Cygwin? Has to be, yes. It's definitely available. Stefan might be interested in patches in that case ;-) In any case 8-) :D It's been some years now, since I've used Cygwin the last time (before moving to the real thing), but basically it should be possible now to build with OpenJDK also a Cygwin-aware JDK. - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Maven 3.x Support
Hi Stefan, Stefan Bodewig wrote: Hi, as expected we can use the existing Maven 2.x builder for Maven 3.x as well, I only needed to ensure the environment variable M2_HOME is overridden when invoking Maven 3.x since the mvn wrapper script uses this to locate Maven's jars for 3.x as well. You don't have to set this environment variable at all. Simply start the appropriate mvn script and the script will set the home on its own. I've merged the code and have installed Maven 3.0 on both machines, so we can now use Maven 3.x as well. Inside the code I've renamed a few classes - we used to have Maven and Maven2 classes, they now are Maven1 and Maven. I've introduced mvn1 as an alias for the old maven and mvn2 as an alias for the old mvn and added mvn3 for Maven 3.x builds - at one point we should probably replace all usage of mvn with mvn2 to make things clearer. Documenation needs to be adapted, I intend to do that tomorrow morning. - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Does anybody Know a Small Maven 3.x Project?
Stefan Bodewig wrote: Hi, I expect it won't be too long before the first projects switch from Maven 2.x to 3.x. From what I've read I'd expect the mvn builder of Gump to work for 3.x as well, but it will certainly have to use a different executable. Does anybody know of a small project that could be a good candidate to put into a testbed in order to test/improve the mvn builder so it works with either version? commons-lang3 ? - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Does anybody Know a Small Maven 3.x Project?
Stefan Bodewig wrote: On 2010-10-27, Jörg Schaible wrote: Stefan Bodewig wrote: Does anybody know of a small project that could be a good candidate to put into a testbed in order to test/improve the mvn builder so it works with either version? commons-lang3 ? Builds fine using Maven 2.2.1 in Gump. Do you mean it should also work with Maven 3.x (is that mvn3?) or that Maven 3.x is in fact the preferred build tool? It works also with M3, but M3 is not required. Actually I've built all released commons artifacts for the vote with M3 (starting with M3 betas) and had never problems because of M3 (apart from site generation which is normally not generated with Gump). - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: skipTests vs maven.test.skip.exec
Niall Pemberton wrote: On Mon, Sep 6, 2010 at 12:16 PM, Stefan Bodewig bode...@apache.org wrote: On 2010-09-06, Niall Pemberton wrote: On Mon, Sep 6, 2010 at 5:03 AM, Stefan Bodewig bode...@apache.org wrote: Hi, some time back we had a discussion that skipTest was the preferred property to use when we want to tell mvn not to run tests - well, it doesn't work, at least not for Cocoon 2.2.x. My theory is that those properties are interpreted by the surefire plugin rather than mvn itself. Yes, they are plugin parameters: http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html Thank you for the confirmation. And from the docs the skipTests parameter was added in version 2.4 of the surefire plugin [...] and cocoon is using version 2.3 of the surefire plugin (see pluginManagement section of the pom): skipTests was introduced to replace the more verbose maven.test.skip=true - you could use that instead though. Is there a difference between maven.test.skip and maven.test.skip.exec (which we use now)? I see there is a skip property in addition to the skipTests property - the former even avoids compilation of the tests, so I gues this is the difference here as well. Yes, the skipTests and maven.test.skip.exec=true are the same - the tests get compiled, but not executed. The maven.test.skip=true doesn't compile or execute the tests. And it will therefore not build attached tests.jars which may result depending artifacts to fail ... - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: BATCH: All dressed up, with nowhere to go...
Dear Plutomeisters, g...@vmgump.apache.org wrote: Dear Gumpmeisters, The following 1 notifys should have been sent *** G U M P [g...@vmgump]: Project portals-pluto-trunk-test (in module [portals-pluto-trunk) failed *** G U M P [g...@vmgump]: Project portals-pluto-trunk-test (in module [portals-pluto-trunk) failed 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 gene...@gump.apache.org. Project portals-pluto-trunk-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - portals-pluto-trunk-test : JSR168 Container Full details are available at: http://vmgump.apache.org/gump/public/portals-pluto-trunk/portals- pluto-trunk-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/portals-pluto-trunk/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/portals-pluto-trunk/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/portals-pluto-trunk/pom.xml The following work was performed: http://vmgump.apache.org/gump/public/portals-pluto-trunk/portals-pluto- trunk-test/gump_work/build_portals-pluto-trunk_portals-pluto-trunk-test.html Work Name: build_portals-pluto-trunk_portals-pluto-trunk-test (Type: Build) Work ended in a state of : Failed Elapsed: 28 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/portals-pluto-trunk/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/portals-pluto-trunk] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/portals- pluto-trunk/pluto-taglib/target/pluto-taglib-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto- util/target/pluto-util-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-container- driver-api/target/pluto-container-driver-api-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-container- api/target/pluto-container-api-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-portal- driver/target/pluto-portal-driver-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto- container/target/pluto-container-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-ant- tasks/target/pluto-ant-tasks-2.0.2-SNAPSHO T.jar:/srv/gump/public/workspace/portals-pluto-trunk/maven-pluto- plugin/target/maven-pluto-plugin-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto-portal- driver-impl/t arget/pluto-portal-driver-impl-2.0.2- SNAPSHOT.jar:/srv/gump/public/workspace/portals-pluto-trunk/pluto- portal/target/pluto-portal-2.0.2-SNAPSHOT.war - [INFO] [ [INFO] org/xmlpull/v1/XmlPullParserFactory org.xmlpull.v1.XmlPullParserFactory [INFO] [ [INFO] Trace java.lang.NoClassDefFoundError: org/xmlpull/v1/XmlPullParserFactory at com.thoughtworks.xstream.io.xml.XppDriver.createParser(XppDriver.java:57) at com.thoughtworks.xstream.io.xml.AbstractXppDriver.createReader(AbstractXppDriver.java:56) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:871) at org.apache.maven.plugin.war.util.WebappStructureSerializer.fromXml(WebappStructureSerializer.java:73) at [snip] It seems somebody is building against the XStream trunk. XStream supports now generic XPP implementations. The spec requires that such an implementation can be loaded normally with the XmlPullFactory, which is unfortunately not part of the Xpp3 library. So you have to do one of this: - use directly the new Xpp3Driver circumventing the usage of the XPP factory - add xmlpull:xmlpull as dependency - use net.sf.kxml:kxml2-min instead of xpp3:xpp3_min as dependency, since it contains the XPP factory as normally required and it seems even faster Cheers, Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Hi Brett, Brett Randall wrote: snip/ I'd bet that the retroweaver will produce everytime the same thing. However, md5sums (ans sha1sum) is generated by the deploy plugin automatically and will always validate the deployed jar itself. - Jörg snip/ For the md5sum I was referring to an md5sum run against .class files extracted from the retro-weaved JAR, varying from build to build. On the bsf-engines module from the 3.x branch, this can be observed by running the following command twice: bsf-engines$ mvn clean install unzip -p target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class | md5sum snip/ c6817d078ad972bcf1716e05e4c7f52f - bsf-engines$ mvn clean install unzip -p target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class | md5sum snip/ 49fb13a50a5c8bbf88823f31ca882680 - Not sure what to make of that - is it retroweaver? Maybe retroweaver places some datetime related info into the instrumented class-file. It have to be retroweaver then.. It doesn't matter, just pointing out that this tripped me when I was trying to fix the build and test that I was producing the exact same artifact with the new build. It turns out that the artifact will be different from build to build without changes, unless I am missing something. That's simply unfortunate. :-/ - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Hi Brett, Brett Randall wrote: On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible joerg.schai...@gmx.de wrote: sebb wrote: On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote: [snip] The question is, why do you install with Ant at all? Simply drop that goal, use the build-helper plugin to attach the artifact and you're done *and* it will be automatically deployed then also. Sounds great - I did not know about that Maven feature. I'll give it a try. Hehe, that explains it ;-) With the build helper you can turn any file into a separate artifact - useful e.g. for XML schemas and the like. At least this will ensure that the bsf-engines will be deployed next time also and the process is transparent for Gump. - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org This is a good outcome and the build is now green on Gump. I hadn't thought of using build-helper but that's a decent option. I actually had this working on my local with a different approach initially suggested by Sebb - changing the primary artifact to jar packaging (from pom), then changing the retroweaver execution/output so that it fed the merged/weaved classes back into the Maven paths, so the normal execution of jar:jar picked them back up and the resulting primary artifact was packaged (and later deployed) as normal by Maven. Using build-helper will result in the jar continuing to be built by Retroweaver rather than being packaged by Maven. This probably doesn't matter - the JAR just won't look like a Maven JAR, contain the metadata etc. Actually there is not really a Maven JAR. It simply the default configuration for Maven's archiver to add the metadata, we turned that off everywhere in the office. So the result of the retroweaver is a perfect artifact. The reason I hadn't published this is that I thought I had made a change that was effecting the binary output - I now suspect that each time Retroweaver runs it produces different binary output (class files) as checked by md5sum, so my solution was probably OK. I'd bet that the retroweaver will produce everytime the same thing. However, md5sums (ans sha1sum) is generated by the deploy plugin automatically and will always validate the deployed jar itself. - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote: On 31/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote: [snip] Actually there is not really a Maven JAR. It simply the default configuration for Maven's archiver to add the metadata, we turned that off everywhere in the office. Huh? What does the last phrase mean? Each plugin that creates a Java archive (jar, ear, war, ...) contains an archive element in its configuration: http://maven.apache.org/shared/maven-archiver/#class_archive Simply set addMavenDescriptor to false So the result of the retroweaver is a perfect artifact. There is a META-INF directory, but it does not contain any Maven properties etc. Exactly what happens when you turn it off ;-) [snip] - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote: On 31/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote: sebb wrote: On 31/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote: [snip] Actually there is not really a Maven JAR. It simply the default configuration for Maven's archiver to add the metadata, we turned that off everywhere in the office. Huh? What does the last phrase mean? Each plugin that creates a Java archive (jar, ear, war, ...) contains an archive element in its configuration: http://maven.apache.org/shared/maven-archiver/#class_archive Simply set addMavenDescriptor to false So the result of the retroweaver is a perfect artifact. There is a META-INF directory, but it does not contain any Maven properties etc. Exactly what happens when you turn it off ;-) I think we are talking about different things here. No, I just pointed out that a JAR is a JAR and even JARs created with Maven may not have the Maven metadata. The jar is currently created by the Ant build script, so does not have the Maven descriptor. AFAICT, changing the addMavenDescriptor setting won't have any effect. I know. So: - do we need the Maven descriptor in the jar? There's no such requirement. - if so, how do we add it? Can the build-helper add it? It's superfluous. - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Hi Brett, Brett Randall wrote: In relation to the long-outstanding build failure of BSF: http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta- bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html I'd like to check the contents of the file /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml . Is that file publicly available, and/or how can I review its contents? I'm wondering if the Gump local repository location for project builds changed in a way incompatible with the BSF/Gump build some time ago. bsf-engines is missing, because it is not deployed. Therefore it is also missing in the official 3.0 release ... - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Brett,
Brett Randall wrote:
In relation to the long-outstanding build failure of BSF:
http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
I'd like to check the contents of the file
/srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml . Is
that
file publicly available, and/or how can I review its contents? I'm
wondering if the Gump local repository location for project builds
changed in a way incompatible with the BSF/Gump build some time ago.
bsf-engines is missing, because it is not deployed.
But it *is* installed as part of the build.xml that downloads the
engines and runs retroweaver on them - have a look earlier in the
build output:
http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
snip
[exec] [INFO] [install:install-file {execution: default-cli}]
[exec] [INFO] Installing
/srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar
to
/home/gump/.m2/repository/org/apache/bsf/bsf-engines/3.0-SNAPSHOT/bsf-
engines-3.0-SNAPSHOT.jar
Yes, but it is not part of the reactor, because it is done by hand. Maven
does not know that it is produced. Don't know if this has an effect on Gump,
but it's quite suspicious that Gump fails to find this artifact. However,
since Gump tries to build the examples, it will fail later anyway, because
some of the dependend stuiff is no longer available.
Therefore it is also missing in the official 3.0 release ...
No, that's because the Maven artifacts were not included in the release
vote.
OK, this is the wrong list for further comments on this. I have to bite my
tongue.
- Jörg
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Brett,
Brett Randall wrote:
In relation to the long-outstanding build failure of BSF:
http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
I'd like to check the contents of the file
/srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml .
Is that
file publicly available, and/or how can I review its contents?
I'm wondering if the Gump local repository location for project
builds changed in a way incompatible with the BSF/Gump build some
time ago.
bsf-engines is missing, because it is not deployed.
But it *is* installed as part of the build.xml that downloads the
engines and runs retroweaver on them - have a look earlier in the
build output:
http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
snip
[exec] [INFO] [install:install-file {execution: default-cli}]
[exec] [INFO] Installing
/srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar
to
/home/gump/.m2/repository/org/apache/bsf/bsf-engines/3.0-SNAPSHOT/bsf-
engines-3.0-SNAPSHOT.jar
Yes, but it is not part of the reactor, because it is done by hand.
Maven
does not know that it is produced. Don't know if this has an effect on
Gump, but it's quite suspicious that Gump fails to find this artifact.
However, since Gump tries to build the examples, it will fail later
anyway, because some of the dependend stuiff is no longer available.
Note that it builds happily on Hudson.
I think the problem is that Gump intercepts repository requests.
No, it is installed to the wrong place - probably because it is done by
hand:
Installing /srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar to /home/gump/.m2/repository/org/apache/bsf/bsf-
engines/3.0-SNAPSHOT/bsf-engines-3.0-SNAPSHOT.jar
vs.
Installing /srv/gump/public/workspace/jakarta-bsf3/bsf-api/target/bsf-
api-3.0-SNAPSHOT.jar to
/srv/gump/public/workspace/mvnlocalrepo/org/apache/bsf/bsf-api/3.0-
SNAPSHOT/bsf-api-3.0-SNAPSHOT.jar
Look at the target path ...
- Jörg
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote:
On 30/03/2010, sebb seb...@gmail.com wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Brett,
Brett Randall wrote:
In relation to the long-outstanding build failure of BSF:
http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
I'd like to check the contents of the file
/srv/gump/public/workspace/jakarta-
bsf3/gump_mvn_settings.xml
. Is that
file publicly available, and/or how can I review its
contents? I'm wondering if the Gump local repository
location for project builds changed in a way incompatible
with the BSF/Gump build some time ago.
bsf-engines is missing, because it is not deployed.
But it *is* installed as part of the build.xml that downloads
the engines and runs retroweaver on them - have a look earlier
in the build output:
http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
snip
[exec] [INFO] [install:install-file {execution:
[default-cli}] exec] [INFO] Installing
/srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar
to
/home/gump/.m2/repository/org/apache/bsf/bsf-engines/3.0-
SNAPSHOT/bsf-
engines-3.0-SNAPSHOT.jar
Yes, but it is not part of the reactor, because it is done by
hand. Maven
does not know that it is produced. Don't know if this has an
effect on Gump, but it's quite suspicious that Gump fails to find
this artifact. However, since Gump tries to build the examples,
it will fail later anyway, because some of the dependend stuiff
is no longer available.
Note that it builds happily on Hudson.
I think the problem is that Gump intercepts repository requests.
No, it is installed to the wrong place - probably because it is done
by
hand:
Installing
/srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar to
/home/gump/.m2/repository/org/apache/bsf/bsf-
engines/3.0-SNAPSHOT/bsf-engines-3.0-SNAPSHOT.jar
vs.
Installing
/srv/gump/public/workspace/jakarta-bsf3/bsf-api/target/bsf-
api-3.0-SNAPSHOT.jar to
/srv/gump/public/workspace/mvnlocalrepo/org/apache/bsf/bsf-api/3.0-
SNAPSHOT/bsf-api-3.0-SNAPSHOT.jar
Look at the target path ...
The command-line parameters are:
install:install-file -DgroupId=org.apache.bsf -DartifactId=bsf-engines
-Dversion=${bsf.version} -Dpackaging=jar -DgeneratePom=true
-Dfile=${basedir}/target/bsf-engines-${bsf.version}.jar
which are perfectly OK for non-Gump usage.
The command-line maven is not picking up the Gump override for the local
repo. So somehow one needs to tell the nested Maven invocation:
--settings
/srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml
However, this *only* needs to be done for Gump runs, as the file won't
exist otherwise.
I'll have a look at that.
There's no documentation on M2 command-line options that I could find
- do you happen to know if the --settings value is saved in a maven
property?
Should have looked at the existing build.xml more thoroughly - the
local repo path is already passed in as it is used for picking up
retroweaver classes.
So I've added it to the maven argument list.
Works OK for me locally; hopefully it will keep Gump happy too.
The question is, why do you install with Ant at all? Simply drop that goal,
use the build-helper plugin to attach the artifact and you're done *and* it
will be automatically deployed then also.
- Jörg
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
On 30/03/2010, sebb seb...@gmail.com wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
On 30/03/2010, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Brett,
Brett Randall wrote:
In relation to the long-outstanding build failure of
BSF:
http://vmgump.apache.org/gump/public/jakarta-
bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
I'd like to check the contents of the file
/srv/gump/public/workspace/jakarta-
bsf3/gump_mvn_settings.xml
. Is that
file publicly available, and/or how can I review its
contents? I'm wondering if the Gump local repository
location for project builds changed in a way
incompatible with the BSF/Gump build some time ago.
bsf-engines is missing, because it is not deployed.
But it *is* installed as part of the build.xml that
downloads the engines and runs retroweaver on them - have a
look earlier in the build output:
http://vmgump.apache.org/gump/public/jakarta-bsf3/jakarta-
bsf3/gump_work/build_jakarta-bsf3_jakarta-bsf3.html
snip
[exec] [INFO] [install:install-file {execution:
[default-cli}] exec] [INFO] Installing
/srv/gump/public/workspace/jakarta-bsf3/bsf-
engines/target/bsf-
engines-3.0-SNAPSHOT.jar
to
/home/gump/.m2/repository/org/apache/bsf/bsf-engines/3.0-
SNAPSHOT/bsf-
engines-3.0-SNAPSHOT.jar
Yes, but it is not part of the reactor, because it is done by
hand. Maven
does not know that it is produced. Don't know if this has an
effect on Gump, but it's quite suspicious that Gump fails to
find this artifact. However, since Gump tries to build the
examples, it will fail later anyway, because some of the
dependend stuiff is no longer available.
Note that it builds happily on Hudson.
I think the problem is that Gump intercepts repository
requests.
No, it is installed to the wrong place - probably because it is
done by
hand:
Installing
/srv/gump/public/workspace/jakarta-bsf3/bsf-engines/target/bsf-
engines-3.0-SNAPSHOT.jar to
/home/gump/.m2/repository/org/apache/bsf/bsf-
engines/3.0-SNAPSHOT/bsf-engines-3.0-SNAPSHOT.jar
vs.
Installing
/srv/gump/public/workspace/jakarta-bsf3/bsf-api/target/bsf-
api-3.0-SNAPSHOT.jar to
/srv/gump/public/workspace/mvnlocalrepo/org/apache/bsf/bsf-
api/3.0-
SNAPSHOT/bsf-api-3.0-SNAPSHOT.jar
Look at the target path ...
The command-line parameters are:
install:install-file -DgroupId=org.apache.bsf
-DartifactId=bsf-engines -Dversion=${bsf.version} -Dpackaging=jar
-DgeneratePom=true
-Dfile=${basedir}/target/bsf-engines-${bsf.version}.jar
which are perfectly OK for non-Gump usage.
The command-line maven is not picking up the Gump override for the
local repo. So somehow one needs to tell the nested Maven
invocation:
--settings
/srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml
However, this *only* needs to be done for Gump runs, as the file
won't
exist otherwise.
I'll have a look at that.
There's no documentation on M2 command-line options that I could
find - do you happen to know if the --settings value is saved in a
maven property?
Should have looked at the existing build.xml more thoroughly - the
local repo path is already passed in as it is used for picking up
retroweaver classes.
So I've added it to the maven argument list.
Works OK for me locally; hopefully it will keep Gump happy too.
The question is, why do you install with Ant at all? Simply drop that
goal,
use the build-helper plugin to attach the artifact and you're done *and*
it will be automatically deployed then also.
Sounds great - I did not know about that Maven feature.
I'll give it a try.
Hehe, that explains it ;-)
With the build helper you can turn any file into a separate artifact -
useful e.g. for XML schemas and the like.
At least this will ensure that the bsf-engines will be deployed next time
also and the process is transparent for Gump.
- Jörg
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Please add relativePath elements to the parent in Excalibur POMs
Stefan Bodewig wrote at Montag, 22. Juni 2009 11:05: Dear Excalibur devs it is great to see Excalibur starting some activity again. When you removed the Maven 1.x buildsystem sometime last week (or so) you forced Gump to use your mvn descriptors (no problem here, other than that of metadata maintenance). So far Gump has split up Excalibur into many small buildable pieces, each one corresponding to a single artifact. Those pieces know how they depend on each other (based on the care by people who knew what they did, i.e. not me 8-). We'd like to keep it that way for the Maven 2 build which means we'd like to build Excalibur without using the reactor build because the later doesn't allow us a state where some of the pieces built successfully and other didn't. The reactor is an all or nothing thing. My first naive conversions (for framework/api and cornerstone/sockets/api) fail because mvn cannot locate the parent POM. It tries to locate it inside the (local) repository but it can't find it there since it has never been deployed there in the first place. Unless anybody with more mvn foo than I have can tell me how to deploy the parent POM (using mvn and no manual intervention of any kind, that is) another option would be if you could provide relativePath elements for all your parent definitions in your POMs. I think this would benefit occasional developers anyway. Simply treat this parent POM as a normal artifact where all other artifacts are depending on. Depending on how the release process is planned, relative paths are not possible at all. - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: updaters now clean bad working copies
Stefan Bodewig wrote at Montag, 2. März 2009 06:21: Hi, I've merged the latest changes from trunk, which means the live branch's cvs, svn and git updaters should now detect working copies for a different SCM or for a different URL (module, tag, ...) and remove before a new clean checkout them instead of just saying update failed. This means if anybody changes the svn URL, we no longer need to remove working copies manually. Great news! Thanks! - Jörg - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Gump PMC Report 12/2006
Stefan Bodewig wrote: On Fri, 15 Dec 2006, Jörg Schaible [EMAIL PROTECTED] wrote: svn info | grep URL | cut -f 2 -d ' ' Gump also supports CVS and Perforce ;-) Yep. But the talk was about moving subversion only. For CVS you can adjust all the CVS/Root files, for P4 you would have to do some sed-magic on the server ... hehehe If the configured URL differs from above a svn switch command can be invoked automatically. It's a bit more complex than that since we may even be switching from CVS to SVN or similar. Not impossible to code, of course, but we don't have that many coders around gump at all. Fair enough :) - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Installing a fresh gump2 yields lots of issues
Hi Stefan, Stefan Bodewig wrote: On Fri, 10 Nov 2006, Stefano Mazzocchi [EMAIL PROTECTED] wrote: First of all, installing the 'full gump' run without vmgump packages, it's a nightmare, nobody with their sane minds would do it. True. Second, while svn doesn't need this, cvs does require the anonymous user to login if the password is not empty... which means, again, that without vmgump's .cvspass, it would be hell. I thought all our repository information contained passwords for CVS and at least the old Gump would create .cvspass files itself (it's not as if CVS used some string encryption for that file). Doesn't it do that anymore? - jmock: cvs repo seems to be no longer available :pserver:[EMAIL PROTECTED]:/cvs/jmock/ - cargo: svn: URL 'svn://svn.cargo.codehaus.org/cargo/scm/cargo/trunk' doesn't exist - groovy: /home/projects/groovy/scm: no such repository are known issues, but we are using the official URLs you get from each project's website. - directory-naming: svn: URL 'http://svn.apache.org/repos/asf/directory/trunks/naming' doesn't exist - geronimo: svn: URL 'http://svn.apache.org/repos/asf/geronimo/trunk' doesn't exist - no idea what the Gump-correct URL would be. There are other repositories that are broken as well: xstream, XStream is http://svn.codehaus.org/xstream/trunk The same scheme applies for all Codehaus' projects based on Subversion (Cargo, Groovy). They all changed after the crash of beaver with the availability of the new infrastructure. Basically you can lookup any of them with: http://xircles.codehaus.org/projects/project name/repo javassist, eyebrowse and beanshell. Problem with stable Gump as opposed to trunk Gump is that it doesn't get flagged as a problem, so I usually look at helios to see whether we have problems the repo information. smartfrog was/is in the process of migrating from CVS to svn and I'd consider the current problem transient - read, Steve is going to fix it once the migration is done. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
[EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 5 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Project xstream (in module xstream) failed [snip] Tried to fix the descriptor... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: No space left on device
Hi Martin, Martin van den Bemt wrote on Sunday, August 27, 2006 7:02 PM: Hi Noel, Thanx for noticing :) Hmm part of the problem seems to be everyone moving to subversion, since you need twice as much diskspace with a subversion checkout compared to a cvs checkout.. So why do a checkout? Wouldn't a simple export be quite sufficient? [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: No space left on device
Martin van den Bemt wrote on Monday, August 28, 2006 8:51 AM: Hmm an export will take the gump run to run eeeh a very long time.. We just do a cvs / svn update afaik. Well, there's always a trade-off. ;-) BTW: There's one thing a svn up will not handle very good - the usage of external Subversion links. I am not sure how frequently they are used within the code base, but if you change the link svn up is not able to deal with the remainders of the previous definition. While I guess, this is a rare situation, it might be good to whipe the source from time to time anyway. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: BATCH: All dressed up, with nowhere to go...
Bill Barker wrote on Monday, March 06, 2006 2:12 AM: -Original Message- From: Sander Temme [mailto:[EMAIL PROTECTED] Sent: Sun 3/5/2006 4:39 PM To: Gump code and data Subject: Re: BATCH: All dressed up, with nowhere to go... On Mar 5, 2006, at 2:43 AM, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]: Project junit (in module junit) failed So, what is the scenario when something like this happens? Do the JUnit folks know? Care? Do we just wait for them to get their s**t together? It looks like somebody forgot to do a 'cvs add' before they did a 'cvs ci'. The current Gump descriptor doesn't nag / so they won't have found out about it from us (although there just was a long discussion of it on [EMAIL PROTECTED] :). Given how inactive the CVS is, I'm guessing that they simply don't know (it works for the person that broke it, and nobody else has done a 'cvs up ant' :). Add David Saff [saff at mit.edu] into the nag if he agrees, he's currently doing the job. [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2
Leo Simons wrote on Friday, November 18, 2005 9:49 AM: On Fri, Nov 18, 2005 at 12:20:39AM -0800, Bill Barker wrote: [snip] I believe that both the Maven1 and Maven2 scripts use $MAVEN_HOME, which is the biggest problem with just creating a mvn/ tag for Gump2. There are also problems with separating the local Maven repository between Gump1 and Gump2. As much as I hate to admit it, having a mvn/ tag in Gump2 looks like it will be a lot of work :(. Do I understand correctly that the problem you see is that - you need different values of MAVEN_HOME - you need different contents of ~/.maven Maven 1 uses MAVEN_HOME (defaults to ~/.maven) Maven 2 uses M2_HOME (defaults to ~/.m2) [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I set a Java system property for a Maven build?
Hi Stefan, Stefan Bodewig wrote on Wednesday, October 26, 2005 6:13 AM: On Tue, 25 Oct 2005, Jörg Schaible [EMAIL PROTECTED] wrote: or use follwoing entries in the project.properties: maven.junit.sysproperties=java.awt.headless java.awt.headless=true Thanks. I'll take a look at it at some point, I'll probably need to modify the Gump/maven integration code for this. We currently don't touch project.properties, only build.properties. Would setting the properties there have the same effect? Depends. Maven reads a build.properties from the user's home dir. I cannot say under what user you're running Maven, but if you put them there, they are picked up. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I set a Java system property for a Maven build?
Jörg Schaible wrote on Wednesday, October 26, 2005 9:59 AM: Hi Stefan, Stefan Bodewig wrote on Wednesday, October 26, 2005 6:13 AM: On Tue, 25 Oct 2005, Jörg Schaible [EMAIL PROTECTED] wrote: or use follwoing entries in the project.properties: maven.junit.sysproperties=java.awt.headless java.awt.headless=true Thanks. I'll take a look at it at some point, I'll probably need to modify the Gump/maven integration code for this. We currently don't touch project.properties, only build.properties. Would setting the properties there have the same effect? Depends. Maven reads a build.properties from the user's home dir. I cannot say under what user you're running Maven, but if you put them there, they are picked up. Correction. Dion is right, Maven will also read build.properties from the current dir. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I set a Java system property for a Maven build?
Dion Gillard wrote on Tuesday, October 25, 2005 7:11 AM:
M1 or M2?
If M1, use -Dprop=value when launching
or from inside jelly code:
${systemScope.put('java.awt.headless', 'true')}
or use follwoing entries in the project.properties:
maven.junit.sysproperties=java.awt.headless
java.awt.headless=true
- Jörg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Reports of failing commons-id
Hi folks, how can I get the error report from the failed test below? This message was originally sent to the commons-dev list. All those tests work on a local machine, so it would be very interesting under what circumstances they fail. - Jörg Adam Jack wrote on Tuesday, September 20, 2005 12:16 PM: [snip] [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/id/target/te st-classes [mkdir] Created dir: /x1/gump/public/workspace/jakarta-commons-sandbox/id/target/te st-reports test:test-resources: test:compile: [javac] Compiling 16 source files to /x1/gump/public/workspace/jakarta-commons-sandbox/id/target/te st-classes test:test: [snip] [junit] Running org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest [junit] Tests run: 9, Failures: 2, Errors: 0, Time elapsed: 1.642 sec [junit] [ERROR] TEST org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest FAILED [snip] - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
