On 30/03/2010, Jörg Schaible <[email protected]> wrote: > sebb wrote: > > > On 30/03/2010, sebb <[email protected]> wrote: > >> On 30/03/2010, Jörg Schaible <[email protected]> wrote: > >> > sebb wrote: > >> > > >> > > On 30/03/2010, Jörg Schaible <[email protected]> wrote: > >> > >> sebb wrote: > >> > >> > >> > >> > On 30/03/2010, Jörg Schaible <[email protected]> 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. > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
