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
