You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Sian January <si...@googlemail.com> on 2010/08/18 09:51:44 UTC

[build] fetch-depends having problems with the sourceforge mirror

I've just run the federated build from scratch and it all went
smoothly except that I had to change the sourceforge mirror in all the
depends.properties file.  Looking at their website [1] "internap"
doesn't seem to be listed at the moment so I think we may need to
switch the scripts to use a different one.  OVH worked for me
yesterday unless anyone has another preference?

Thanks,

Sian

[1] http://sourceforge.net/apps/trac/sourceforge/wiki/Mirrors

-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [build] fetch-depends having problems with the sourceforge mirror

Posted by sebb <se...@gmail.com>.
On 1 September 2010 13:45, Tim Ellison <t....@gmail.com> wrote:
> On 01/Sep/2010 11:53, Mark Hindess wrote:
>> In message <4C...@gmail.com>, Tim Ellison writes:
>>> On 24/Aug/2010 16:46, Sian January wrote:
>>>> On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
>>>>> On 18/Aug/2010 08:51, Sian January wrote:
>>>>>> I've just run the federated build from scratch and it all went
>>>>>> smoothly except that I had to change the sourceforge mirror in all the
>>>>>> depends.properties file.  Looking at their website [1] "internap"
>>>>>> doesn't seem to be listed at the moment so I think we may need to
>>>>>> switch the scripts to use a different one.  OVH worked for me
>>>>>> yesterday unless anyone has another preference?
>>>>> Almost by definition it is unlikely that any one mirror will satisfy
>>>>> everyone.
>>>>>
>>>>> It should be possible to specify the chosen SourceForge mirror site used
>>>>> at build time by defining the ant property -Dsf.base= though looking at
>>>>> the depends.properties file I see not all URLs have been rewritten to
>>>>> use that base property yet.
>>>>>
>>>>> I didn't see anything obvious for how to dynamically find your best
>>>>> mirror for using SF.
>>>> Looks like you can add ?use_mirror=autoselect to the end of the URL
>>>>
>>>> e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
>>>>
>>>> Shall I update the build files to use this instead?
>>> Sounds good, but let's wait until after the milestone to avoid any
>>> unforeseen problems that may appear with more testing.
>>
>> I don't think we should release source artifacts that have obviously
>> broken fetch-depends URLs.  It would be confusing and inconvenient for
>> those trying to use these artifacts.  More importantly, none of my
>> automated scripts for creating the linux/debian artifacts will work and
>> doing them manually would be more error-prone and would require much
>> more time than I have available at the moment.
>>
>> I don't mind if we don't fix all of the urls to use the mirror
>> auto-selection but I do think we need to fix them to point at a working
>> mirror.
>>
>> We already use dfn.dl.sourceforge.net for some downloads so I suggest
>> just doing search/replace of internap with dfn on the problematic URLs.
>> Please can I have permission to commit this change?
>
> I thought it was a temporary outage that I've seen before, but it's been
> a while and the download from internap does seem to have disappeared.
>
> I'm +1 to switching to another mirror for now, and working with the
> autoselect mechanism after the milestone.

If a jar is available from Maven central, perhaps consider switching
to that instead?

e.g. in this case use

http://repo1.maven.org/maven2/mx4j/mx4j/3.0.2/

or one of the other mx4j Maven directories.

There will probably still be some jars that have to come from SF.

Re: [build] fetch-depends having problems with the sourceforge mirror

Posted by Tim Ellison <t....@gmail.com>.
On 01/Sep/2010 11:53, Mark Hindess wrote:
> In message <4C...@gmail.com>, Tim Ellison writes:
>> On 24/Aug/2010 16:46, Sian January wrote:
>>> On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
>>>> On 18/Aug/2010 08:51, Sian January wrote:
>>>>> I've just run the federated build from scratch and it all went
>>>>> smoothly except that I had to change the sourceforge mirror in all the
>>>>> depends.properties file.  Looking at their website [1] "internap"
>>>>> doesn't seem to be listed at the moment so I think we may need to
>>>>> switch the scripts to use a different one.  OVH worked for me
>>>>> yesterday unless anyone has another preference?
>>>> Almost by definition it is unlikely that any one mirror will satisfy
>>>> everyone.
>>>>
>>>> It should be possible to specify the chosen SourceForge mirror site used
>>>> at build time by defining the ant property -Dsf.base= though looking at
>>>> the depends.properties file I see not all URLs have been rewritten to
>>>> use that base property yet.
>>>>
>>>> I didn't see anything obvious for how to dynamically find your best
>>>> mirror for using SF.
>>> Looks like you can add ?use_mirror=autoselect to the end of the URL
>>>
>>> e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
>>>
>>> Shall I update the build files to use this instead?
>> Sounds good, but let's wait until after the milestone to avoid any
>> unforeseen problems that may appear with more testing.
> 
> I don't think we should release source artifacts that have obviously
> broken fetch-depends URLs.  It would be confusing and inconvenient for
> those trying to use these artifacts.  More importantly, none of my
> automated scripts for creating the linux/debian artifacts will work and
> doing them manually would be more error-prone and would require much
> more time than I have available at the moment.
> 
> I don't mind if we don't fix all of the urls to use the mirror
> auto-selection but I do think we need to fix them to point at a working
> mirror.
> 
> We already use dfn.dl.sourceforge.net for some downloads so I suggest
> just doing search/replace of internap with dfn on the problematic URLs.
> Please can I have permission to commit this change?

I thought it was a temporary outage that I've seen before, but it's been
a while and the download from internap does seem to have disappeared.

I'm +1 to switching to another mirror for now, and working with the
autoselect mechanism after the milestone.

Regards,
Tim

Re: [build] fetch-depends having problems with the sourceforge mirror

Posted by Mark Hindess <ma...@googlemail.com>.
In message <4C...@gmail.com>, Tim Ellison writes:
>
> On 24/Aug/2010 16:46, Sian January wrote:
> > On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
> >> On 18/Aug/2010 08:51, Sian January wrote:
> >>> I've just run the federated build from scratch and it all went
> >>> smoothly except that I had to change the sourceforge mirror in all the
> >>> depends.properties file.  Looking at their website [1] "internap"
> >>> doesn't seem to be listed at the moment so I think we may need to
> >>> switch the scripts to use a different one.  OVH worked for me
> >>> yesterday unless anyone has another preference?
> >> Almost by definition it is unlikely that any one mirror will satisfy
> >> everyone.
> >>
> >> It should be possible to specify the chosen SourceForge mirror site used
> >> at build time by defining the ant property -Dsf.base= though looking at
> >> the depends.properties file I see not all URLs have been rewritten to
> >> use that base property yet.
> >>
> >> I didn't see anything obvious for how to dynamically find your best
> >> mirror for using SF.
> > 
> > Looks like you can add ?use_mirror=autoselect to the end of the URL
> > 
> > e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
> > 
> > Shall I update the build files to use this instead?
> 
> Sounds good, but let's wait until after the milestone to avoid any
> unforeseen problems that may appear with more testing.

I don't think we should release source artifacts that have obviously
broken fetch-depends URLs.  It would be confusing and inconvenient for
those trying to use these artifacts.  More importantly, none of my
automated scripts for creating the linux/debian artifacts will work and
doing them manually would be more error-prone and would require much
more time than I have available at the moment.

I don't mind if we don't fix all of the urls to use the mirror
auto-selection but I do think we need to fix them to point at a working
mirror.

We already use dfn.dl.sourceforge.net for some downloads so I suggest
just doing search/replace of internap with dfn on the problematic URLs.
Please can I have permission to commit this change?

Regards,
-Mark.

Re: [build] fetch-depends having problems with the sourceforge mirror

Posted by Tim Ellison <t....@gmail.com>.
On 24/Aug/2010 16:46, Sian January wrote:
> On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
>> On 18/Aug/2010 08:51, Sian January wrote:
>>> I've just run the federated build from scratch and it all went
>>> smoothly except that I had to change the sourceforge mirror in all the
>>> depends.properties file.  Looking at their website [1] "internap"
>>> doesn't seem to be listed at the moment so I think we may need to
>>> switch the scripts to use a different one.  OVH worked for me
>>> yesterday unless anyone has another preference?
>> Almost by definition it is unlikely that any one mirror will satisfy
>> everyone.
>>
>> It should be possible to specify the chosen SourceForge mirror site used
>> at build time by defining the ant property -Dsf.base= though looking at
>> the depends.properties file I see not all URLs have been rewritten to
>> use that base property yet.
>>
>> I didn't see anything obvious for how to dynamically find your best
>> mirror for using SF.
> 
> Looks like you can add ?use_mirror=autoselect to the end of the URL
> 
> e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
> 
> Shall I update the build files to use this instead?

Sounds good, but let's wait until after the milestone to avoid any
unforeseen problems that may appear with more testing.

Regards,
Tim

Re: [build] fetch-depends having problems with the sourceforge mirror

Posted by Sian January <si...@googlemail.com>.
On 27 September 2010 13:52, Tim Ellison <t....@gmail.com> wrote:
> On 24/Aug/2010 16:46, Sian January wrote:
>> On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
>>> On 18/Aug/2010 08:51, Sian January wrote:
>>>> I've just run the federated build from scratch and it all went
>>>> smoothly except that I had to change the sourceforge mirror in all the
>>>> depends.properties file.  Looking at their website [1] "internap"
>>>> doesn't seem to be listed at the moment so I think we may need to
>>>> switch the scripts to use a different one.  OVH worked for me
>>>> yesterday unless anyone has another preference?
>>> Almost by definition it is unlikely that any one mirror will satisfy
>>> everyone.
>>>
>>> It should be possible to specify the chosen SourceForge mirror site used
>>> at build time by defining the ant property -Dsf.base= though looking at
>>> the depends.properties file I see not all URLs have been rewritten to
>>> use that base property yet.
>>>
>>> I didn't see anything obvious for how to dynamically find your best
>>> mirror for using SF.
>>
>> Looks like you can add ?use_mirror=autoselect to the end of the URL
>>
>> e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
>>
>> Shall I update the build files to use this instead?
>
> I think you can go ahead now Sian.  See also HARMONY-6658.

Main build files updated at r1002080 and vts build file mentioned in
HARMONY-6658 updated at r1002109

>
> Regards,
> Tim
>
>



-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [build] fetch-depends having problems with the sourceforge mirror

Posted by Tim Ellison <t....@gmail.com>.
On 24/Aug/2010 16:46, Sian January wrote:
> On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
>> On 18/Aug/2010 08:51, Sian January wrote:
>>> I've just run the federated build from scratch and it all went
>>> smoothly except that I had to change the sourceforge mirror in all the
>>> depends.properties file.  Looking at their website [1] "internap"
>>> doesn't seem to be listed at the moment so I think we may need to
>>> switch the scripts to use a different one.  OVH worked for me
>>> yesterday unless anyone has another preference?
>> Almost by definition it is unlikely that any one mirror will satisfy
>> everyone.
>>
>> It should be possible to specify the chosen SourceForge mirror site used
>> at build time by defining the ant property -Dsf.base= though looking at
>> the depends.properties file I see not all URLs have been rewritten to
>> use that base property yet.
>>
>> I didn't see anything obvious for how to dynamically find your best
>> mirror for using SF.
> 
> Looks like you can add ?use_mirror=autoselect to the end of the URL
> 
> e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect
> 
> Shall I update the build files to use this instead?

I think you can go ahead now Sian.  See also HARMONY-6658.

Regards,
Tim

Re: [build] fetch-depends having problems with the sourceforge mirror

Posted by Sian January <si...@googlemail.com>.
On 19 August 2010 03:29, Tim Ellison <t....@gmail.com> wrote:
> On 18/Aug/2010 08:51, Sian January wrote:
>> I've just run the federated build from scratch and it all went
>> smoothly except that I had to change the sourceforge mirror in all the
>> depends.properties file.  Looking at their website [1] "internap"
>> doesn't seem to be listed at the moment so I think we may need to
>> switch the scripts to use a different one.  OVH worked for me
>> yesterday unless anyone has another preference?
>
> Almost by definition it is unlikely that any one mirror will satisfy
> everyone.
>
> It should be possible to specify the chosen SourceForge mirror site used
> at build time by defining the ant property -Dsf.base= though looking at
> the depends.properties file I see not all URLs have been rewritten to
> use that base property yet.
>
> I didn't see anything obvious for how to dynamically find your best
> mirror for using SF.

Looks like you can add ?use_mirror=autoselect to the end of the URL

e.g. http://downloads.sourceforge.net/sourceforge/mx4j/mx4j-3.0.2.zip?use_mirror=autoselect

Shall I update the build files to use this instead?

>
> Regards,
> Tim
>
>> Thanks,
>>
>> Sian
>>
>> [1] http://sourceforge.net/apps/trac/sourceforge/wiki/Mirrors
>>
>



-- 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Re: [build] fetch-depends having problems with the sourceforge mirror

Posted by Tim Ellison <t....@gmail.com>.
On 18/Aug/2010 08:51, Sian January wrote:
> I've just run the federated build from scratch and it all went
> smoothly except that I had to change the sourceforge mirror in all the
> depends.properties file.  Looking at their website [1] "internap"
> doesn't seem to be listed at the moment so I think we may need to
> switch the scripts to use a different one.  OVH worked for me
> yesterday unless anyone has another preference?

Almost by definition it is unlikely that any one mirror will satisfy
everyone.

It should be possible to specify the chosen SourceForge mirror site used
at build time by defining the ant property -Dsf.base= though looking at
the depends.properties file I see not all URLs have been rewritten to
use that base property yet.

I didn't see anything obvious for how to dynamically find your best
mirror for using SF.

Regards,
Tim

> Thanks,
> 
> Sian
> 
> [1] http://sourceforge.net/apps/trac/sourceforge/wiki/Mirrors
>