Re: Access to Maven settings for BSF Gump build
On 01/04/2010, Jörg Schaible wrote: > Hi Brett, > > Brett Randall wrote: > > > > > >> > >> 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 > >> > > > > > > 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 > > > > c6817d078ad972bcf1716e05e4c7f52f - > > bsf-engines$ mvn clean install && unzip -p > > target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class | > > md5sum > > > > 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-unsubscr...@gump.apache.org > For additional commands, e-mail: general-h...@gump.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Hi Brett, Brett Randall wrote: > >> >> 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 >> > > > 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 > > c6817d078ad972bcf1716e05e4c7f52f - > bsf-engines$ mvn clean install && unzip -p > target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class | > md5sum > > 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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
> > 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 > 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 c6817d078ad972bcf1716e05e4c7f52f - bsf-engines$ mvn clean install && unzip -p target/bsf-engines-3.0-SNAPSHOT.jar bsh/engine/BshScriptEngine.class | md5sum 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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote: > On 31/03/2010, Jörg Schaible wrote: >> sebb wrote: >> >> > On 31/03/2010, Jörg Schaible 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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
On 31/03/2010, Jörg Schaible wrote: > sebb wrote: > > > On 31/03/2010, Jörg Schaible 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-unsubscr...@gump.apache.org > For additional commands, e-mail: general-h...@gump.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote: > On 31/03/2010, Jörg Schaible 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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
On 31/03/2010, Jörg Schaible wrote: > Hi Brett, > > Brett Randall wrote: > > > > On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible > > wrote: > >> sebb wrote: > >> > >>> On 30/03/2010, Jörg Schaible 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-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. > > > 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-unsubscr...@gump.apache.org > For additional commands, e-mail: general-h...@gump.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
Hi Brett, Brett Randall wrote: > On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible > wrote: >> sebb wrote: >> >>> On 30/03/2010, Jörg Schaible 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-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. 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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
On Tue, Mar 30, 2010 at 11:03 PM, Jörg Schaible wrote:
> sebb wrote:
>
>> On 30/03/2010, Jörg Schaible wrote:
>>> sebb wrote:
>>>
>>> > On 30/03/2010, sebb wrote:
>>> >> On 30/03/2010, Jörg Schaible wrote:
>>> >> > sebb wrote:
>>> >> >
>>> >> > > On 30/03/2010, Jörg Schaible wrote:
>>> >> > >> sebb wrote:
>>> >> > >>
>>> >> > >> > On 30/03/2010, Jörg Schaible 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
>>> >> > >> >
>>> >> > >> >
>>> >> > >> > [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-
>>> &g
Re: Access to Maven settings for BSF Gump build
sebb wrote:
> On 30/03/2010, Jörg Schaible wrote:
>> sebb wrote:
>>
>> > On 30/03/2010, sebb wrote:
>> >> On 30/03/2010, Jörg Schaible wrote:
>> >> > sebb wrote:
>> >> >
>> >> > > On 30/03/2010, Jörg Schaible wrote:
>> >> > >> sebb wrote:
>> >> > >>
>> >> > >> > On 30/03/2010, Jörg Schaible 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
>> >> > >> >
>> >> > >> >
>> >> > >> > [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
Re: Access to Maven settings for BSF Gump build
On 30/03/2010, Jörg Schaible wrote:
> sebb wrote:
>
> > On 30/03/2010, sebb wrote:
> >> On 30/03/2010, Jörg Schaible wrote:
> >> > sebb wrote:
> >> >
> >> > > On 30/03/2010, Jörg Schaible wrote:
> >> > >> sebb wrote:
> >> > >>
> >> > >> > On 30/03/2010, Jörg Schaible 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
> >> > >> >
> >> > >> >
> >> > >> > [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:
> >&
Re: Access to Maven settings for BSF Gump build
sebb wrote:
> On 30/03/2010, sebb wrote:
>> On 30/03/2010, Jörg Schaible wrote:
>> > sebb wrote:
>> >
>> > > On 30/03/2010, Jörg Schaible wrote:
>> > >> sebb wrote:
>> > >>
>> > >> > On 30/03/2010, Jörg Schaible 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
>> > >> >
>> > >> >
>> > >> > [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
Re: Access to Maven settings for BSF Gump build
On 30/03/2010, sebb wrote:
> On 30/03/2010, Jörg Schaible wrote:
> > sebb wrote:
> >
> > > On 30/03/2010, Jörg Schaible wrote:
> > >> sebb wrote:
> > >>
> > >> > On 30/03/2010, Jörg Schaible 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
> > >> >
> > >> >
> > >> > [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-unsubscr...@gump.apache.org
> > For additional commands, e-mail: general-h...@gump.apache.org
> >
> >
>
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
On 30/03/2010, Jörg Schaible wrote:
> sebb wrote:
>
> > On 30/03/2010, Jörg Schaible wrote:
> >> sebb wrote:
> >>
> >> > On 30/03/2010, Jörg Schaible 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
> >> >
> >> >
> >> > [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-unsubscr...@gump.apache.org
> For additional commands, e-mail: general-h...@gump.apache.org
>
>
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote:
> On 30/03/2010, Jörg Schaible wrote:
>> sebb wrote:
>>
>> > On 30/03/2010, Jörg Schaible 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
>> >
>> >
>> > [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-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
On 30/03/2010, Jörg Schaible wrote:
> sebb wrote:
>
> > On 30/03/2010, Jörg Schaible 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
> >
> >
> > [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-unsubscr...@gump.apache.org
> For additional commands, e-mail: general-h...@gump.apache.org
>
>
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
sebb wrote:
> On 30/03/2010, Jörg Schaible 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
>
>
> [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-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
On 30/03/2010, Jörg Schaible 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
[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-unsubscr...@gump.apache.org
> For additional commands, e-mail: general-h...@gump.apache.org
>
>
-
To unsubscribe, e-mail: general-unsubscr...@gump.apache.org
For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
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-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
Re: Access to Maven settings for BSF Gump build
On 29/03/2010, 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. $ 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 /srv/gump/public/workspace/mvnlocalrepo gump-central Gump proxying central http://localhost:8192/maven2 central gump-apache.snapshots Gump proxying apache.snapshots http://localhost:8192/repo/m2-snapshot-repository apache.snapshots gump-maven2-repository.dev.java.net Gump proxying maven2-repository.dev.java.net http://localhost:8192/maven/2 maven2-repository.dev.java.net cut here === > Thanks > > Brett > - To unsubscribe, e-mail: general-unsubscr...@gump.apache.org For additional commands, e-mail: general-h...@gump.apache.org
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: BSF
Adam R. B. Jack wrote: Anybody aware of the status of BSF? It got donated to the ASF: http://jakarta.apache.org/bsf/ - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BSF
Anybody aware of the status of BSF? http://brutus.apache.org/gump/jdk15/bsf/index.html The update attempt gives: /usr/cvs/bsf: no such repository I go to the registered URL and I get: http://oss.software.ibm.com/developerworks/projects/bsf No such project.Anybody know anything, before I attempt to contact [EMAIL PROTECTED]: Gump has been 'hiding' (unintentionally) a bunch of CVS update failures. I need to fix that, and have them make some noise.regardsAdam -- Experience the Unwired Enterprise: http://www.sybase.com/unwiredenterprise Try Sybase: http://www.try.sybase.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
