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

Reply via email to