You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Brett Randall <br...@Endeca.com> on 2010/03/29 03:25:44 UTC
Access to Maven settings for BSF Gump build
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.
Thanks
Brett
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 29/03/2010, Brett Randall <br...@endeca.com> 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.
$ ls -l /srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml
-rw-r--r-- 1 gump gump 1127 2010-03-30 16:08
/srv/gump/public/workspace/jakarta-bsf3/gump_mvn_settings.xml
======= cut here ========
<?xml version="1.0"?>
<!--
# DO NOT EDIT DO NOT EDIT DO NOT EDIT DO NOT EDIT DO NOT EDIT DO
NOT EDIT DO NOT EDIT
#
# File Automatically Generated by Gump, see http://gump.apache.org/
#
# Generated For : jakarta-bsf3
# Generated At : 2010-03-30 08:08:02
#
#
# DO NOT EDIT DO NOT EDIT DO NOT EDIT DO NOT EDIT DO NOT EDIT DO
NOT EDIT DO NOT EDIT
-->
<settings>
<localRepository>/srv/gump/public/workspace/mvnlocalrepo</localRepository><mirrors>
<mirror>
<id>gump-central</id>
<name>Gump proxying central</name>
<url>http://localhost:8192/maven2</url>
<mirrorOf>central</mirrorOf>
</mirror>
<mirror>
<id>gump-apache.snapshots</id>
<name>Gump proxying apache.snapshots</name>
<url>http://localhost:8192/repo/m2-snapshot-repository</url>
<mirrorOf>apache.snapshots</mirrorOf>
</mirror>
<mirror>
<id>gump-maven2-repository.dev.java.net</id>
<name>Gump proxying maven2-repository.dev.java.net</name>
<url>http://localhost:8192/maven/2</url>
<mirrorOf>maven2-repository.dev.java.net</mirrorOf>
</mirror></mirrors></settings>
============ cut here ===========
> Thanks
>
> Brett
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 01/04/2010, Jörg Schaible <jo...@gmx.de> wrote:
> 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.
>
If you compare the classfiles, the last few bytes of each file are
slightly different.
Dunno if this is a datestamp or not.
However, the dates of the class files are also different; this is
probably caused by the repackaging process in the Ant script.
> It have to be retroweaver then..
And Ant.
>
> > 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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 31/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>> sebb wrote:
>>
>> > On 31/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 31/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> sebb wrote:
>
> > On 31/03/2010, Jörg Schaible <jo...@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.
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.
So:
- do we need the Maven descriptor in the jar?
- if so, how do we add it? Can the build-helper add it?
> [snip]
>
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 31/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 31/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> Hi Brett,
>
> Brett Randall wrote:
>
>
> > On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible <jo...@gmx.de>
> > wrote:
> >> sebb wrote:
> >>
> >>> On 30/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
> >> For additional commands, e-mail: general-help@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.
Huh? What does the last phrase mean?
> 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.
>
> > 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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Brett Randall <ja...@gmail.com>.
<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 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.
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Brett,
Brett Randall wrote:
> On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible <jo...@gmx.de>
> wrote:
>> sebb wrote:
>>
>>> On 30/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
>> For additional commands, e-mail: general-help@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Brett Randall <ja...@gmail.com>.
On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible <jo...@gmx.de> wrote:
> sebb wrote:
>
>> On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>>> sebb wrote:
>>>
>>> > On 30/03/2010, sebb <se...@gmail.com> wrote:
>>> >> On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>>> >> > sebb wrote:
>>> >> >
>>> >> > > On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>>> >> > >> sebb wrote:
>>> >> > >>
>>> >> > >> > On 30/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>> sebb wrote:
>>
>> > On 30/03/2010, sebb <se...@gmail.com> wrote:
>> >> On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>> >> > sebb wrote:
>> >> >
>> >> > > On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>> >> > >> sebb wrote:
>> >> > >>
>> >> > >> > On 30/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> sebb wrote:
>
> > On 30/03/2010, sebb <se...@gmail.com> wrote:
> >> On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> >> > sebb wrote:
> >> >
> >> > > On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> >> > >> sebb wrote:
> >> > >>
> >> > >> > On 30/03/2010, Jörg Schaible <jo...@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.
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 30/03/2010, sebb <se...@gmail.com> wrote:
>> On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>> > sebb wrote:
>> >
>> > > On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>> > >> sebb wrote:
>> > >>
>> > >> > On 30/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 30/03/2010, sebb <se...@gmail.com> wrote:
> On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> > sebb wrote:
> >
> > > On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> > >> sebb wrote:
> > >>
> > >> > On 30/03/2010, Jörg Schaible <jo...@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.
>
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> > For additional commands, e-mail: general-help@gump.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> sebb wrote:
>
> > On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> >> sebb wrote:
> >>
> >> > On 30/03/2010, Jörg Schaible <jo...@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?
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
>> sebb wrote:
>>
>> > On 30/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 30/03/2010, Jörg Schaible <jo...@gmx.de> wrote:
> sebb wrote:
>
> > On 30/03/2010, Jörg Schaible <jo...@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.
> >
> >> 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-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
sebb wrote:
> On 30/03/2010, Jörg Schaible <jo...@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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by sebb <se...@gmail.com>.
On 30/03/2010, Jörg Schaible <jo...@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
> 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.
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Posted by Jörg Schaible <jo...@gmx.de>.
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-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org