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:
>>> 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
>
>

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.

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.

Brett

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

Reply via email to