You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by OmPrakash Muppirala <bi...@gmail.com> on 2014/10/09 20:52:27 UTC
Solution to OSMF/Sourceforge problem with Installer
How about we download the OSMF swc during the release build stage and
package it with the SDK artifact like we do other third party dependencies
like Batik, Velocity and Xerces?
Pros:
* Since we resolve this dependency during build time, end users don't get
affected by Sourceforge downtimes
* If Sourceforge is down when we make the build, we just get the dependency
from our previous good build. OSMF has not changed for a while
* Our Installer already has a way to force users to accept the license for
OSMF. So very little change required to the Installer.
Cons (?):
* OSMF would have to be made a 'required' component instead of 'optional'.
Since it is a small, single file, I don't think this is quite a problem.
* Installer needs to be reworked a bit, to eliminate the optional OSMF
download path. Should not be a major change.
What do folks think of this proposal?
Thanks,
Om
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
My understating of bundling category B software is that it OK to include the binary, and you only need to prompt the user to download the source. [1] So what we are doing goes beyond what is the minimal legal requirement. Do you need to agree to licence terms when you use firefox for instance? No - there is no EULA with Mozilla. [4]
If we where to bundle it in the binary release we would of course need to add something to LICENSE. See [1][2] for full details. The resolution was a while ago (back in Apache 1.1 days?) so not sure if NOTICE modification is required or not, it been discussed on but was unable to find a clear answer. An example of MPL in apache software is cocoon, they modify LICENSE and not NOTICE: [3]
Thanks,
Justin
1. http://www.apache.org/legal/resolved.html#category-b
2. https://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_08_17.txt (look under allow redistribution of MPL- and NPL-licensed executables)
3. https://github.com/apache/cocoon/tree/BRANCH_2_1_X/legal
4. https://www.mozilla.org/en-US/about/legal/eula/
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Tom Chiverton <tc...@extravision.com>.
Nobody reads them anyway.
Tom
On 09/10/14 20:53, Alex Harui wrote:
> One risk of my
> suggestion is that the MPL portion will be “below the fold” and folks
> might miss it.
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Over the last month we've had more than 1000 errors trying to download osmf, but most of these occurred in the last week.
The other download seem more problematic over the last month and a bit we've had:
- 230 or so errors for agij40.jar
- 80 or so errors for afe.jar
Both of these have a higher rate than the normal background osmf error rate.
Justin
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Alex Harui <ah...@adobe.com>.
On 10/9/14, 12:49 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>IMO, the LICENSE we show for the main package would have the MPL stuff in
>> it, not just the AL license, so then there wouldn¹t be a checkbox to
>>check.
>>
>
>Ah, this is so much better than what I had proposed. Just add the MPL
>license text and url along with the Apache license text and link for the
>Flex SDK selection.
>
>
>>
>> But I think we could do it your way as well without changing the
>> Installer. IIRC, having options to choose from just sets flags for the
>> ant script. What the ant script does is independent.
>>
>
>I now feel this is harder than your suggestion :-) Whichever option you
>think is easier.
>
We might want to try it out and get some opinions. One risk of my
suggestion is that the MPL portion will be “below the fold” and folks
might miss it. Might be also worth waiting a day or two before trying it
so other folks can offer their thoughts.
-Alex
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Oct 9, 2014 at 12:43 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 10/9/14, 12:34 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Thu, Oct 9, 2014 at 12:26 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> The set of required and optional steps for new installs is determined
> >>by a
> >> config file. The FlexJS install, for example, doesn¹t offer or install
> >> OSMF. I think we can control everything from the config file and
> >> installer.xml, which would be desirable for our Linux users anyway.
> >>
> >>
> >But, won't removing the OSMF required item from installer.xml remove it
> >from the list of licenses as well? We still want to show that because the
> >user has to explicitly agree to MPL license before proceeding with the
> >installation.
> >
> >I guess the Installer needs to interpret a new variable from the
> >installer.xml that says 'For this component, just display license, don't
> >download it'. Right?
> >
> IMO, the LICENSE we show for the main package would have the MPL stuff in
> it, not just the AL license, so then there wouldn¹t be a checkbox to check.
>
Ah, this is so much better than what I had proposed. Just add the MPL
license text and url along with the Apache license text and link for the
Flex SDK selection.
>
> But I think we could do it your way as well without changing the
> Installer. IIRC, having options to choose from just sets flags for the
> ant script. What the ant script does is independent.
>
I now feel this is harder than your suggestion :-) Whichever option you
think is easier.
>
> The Installer (for new installs) now only does 3 things:
> 1) Displays a product selector that gets a set of products from
> sdk-installer-config-4.0.xml
> 2) If a non-legacy product is selected, it looks up a config file for the
> list of required and optional licenses/components
> 3) Once all required licenses are selected, launches an ant script with
> various ant properties set.
>
Thanks,
Om
>
> -Alex
>
>
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Alex Harui <ah...@adobe.com>.
On 10/9/14, 12:34 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Thu, Oct 9, 2014 at 12:26 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> The set of required and optional steps for new installs is determined
>>by a
>> config file. The FlexJS install, for example, doesn¹t offer or install
>> OSMF. I think we can control everything from the config file and
>> installer.xml, which would be desirable for our Linux users anyway.
>>
>>
>But, won't removing the OSMF required item from installer.xml remove it
>from the list of licenses as well? We still want to show that because the
>user has to explicitly agree to MPL license before proceeding with the
>installation.
>
>I guess the Installer needs to interpret a new variable from the
>installer.xml that says 'For this component, just display license, don't
>download it'. Right?
>
IMO, the LICENSE we show for the main package would have the MPL stuff in
it, not just the AL license, so then there wouldn¹t be a checkbox to check.
But I think we could do it your way as well without changing the
Installer. IIRC, having options to choose from just sets flags for the
ant script. What the ant script does is independent.
The Installer (for new installs) now only does 3 things:
1) Displays a product selector that gets a set of products from
sdk-installer-config-4.0.xml
2) If a non-legacy product is selected, it looks up a config file for the
list of required and optional licenses/components
3) Once all required licenses are selected, launches an ant script with
various ant properties set.
-Alex
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Oct 9, 2014 at 12:26 PM, Alex Harui <ah...@adobe.com> wrote:
> The set of required and optional steps for new installs is determined by a
> config file. The FlexJS install, for example, doesn’t offer or install
> OSMF. I think we can control everything from the config file and
> installer.xml, which would be desirable for our Linux users anyway.
>
>
But, won't removing the OSMF required item from installer.xml remove it
from the list of licenses as well? We still want to show that because the
user has to explicitly agree to MPL license before proceeding with the
installation.
I guess the Installer needs to interpret a new variable from the
installer.xml that says 'For this component, just display license, don't
download it'. Right?
> -Alex
>
> On 10/9/14, 12:20 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Thu, Oct 9, 2014 at 12:15 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> Why do we need to change the installer? What part can’t be done in the
> >> ant script?
> >>
> >
> >Is it possible to stop OSMF download by just changing the installer.xml?
> >
> >I was also thinking about changing the wording from 'optional' to
> >'required', and the multiple locale changes that would be required. I
> >guess there is no need to change the Installer if OSMF is already a
> >required component. Bottom line is that the Installer will not allow you
> >to proceed until you explicitly select OSMF and agree to the MPL license.
> >
> >Thanks,
> >Om
> >
> >
> >>
> >> On 10/9/14, 12:10 PM, "OmPrakash Muppirala" <bi...@gmail.com>
> >>wrote:
> >>
> >> >On Thu, Oct 9, 2014 at 12:03 PM, Alex Harui <ah...@adobe.com> wrote:
> >> >
> >> >> No particular objection. Are you suggesting we go back and
> >>re-release
> >> >>all
> >> >> previous releases or is this just for the future?
> >> >>
> >> >
> >> >I think just for future. This requires a change to both the SDK
> >>(release
> >> >build script) as well as the Installer. It would be better if we make
> >>a
> >> >clean break from the past. So, this means that if someone wants to
> >> >download Flex SDK verion equal to or lower 4.13, they need to use
> >> >Installer
> >> >3.1 or lower. For Flex 4.14 and higher, they need Installer 3.2.
> >> >
> >> >We have done the same exact thing in the past when we made TLF part of
> >>the
> >> >SDK and no one really complained about it.
> >> >
> >> >
> >> >>
> >> >> I¹m not sure OSMF is the main culprit for failed downloads. AIR was
> >> >>more
> >> >> likely to choke for me in recent testing.
> >> >>
> >> >
> >> >From all the complaints we are receiving, it seems that fixing the OSMF
> >> >question would bring a lot of stability to the Installer. Plus, I feel
> >> >that the Adobe servers are a more resilient than the SourceForge
> >>servers.
> >> >
> >> >Thanks,
> >> >Om
> >> >
> >> >
> >> >>
> >> >> -Alex
> >> >>
> >> >> On 10/9/14, 11:52 AM, "OmPrakash Muppirala" <bi...@gmail.com>
> >> >>wrote:
> >> >>
> >> >> >How about we download the OSMF swc during the release build stage
> >>and
> >> >> >package it with the SDK artifact like we do other third party
> >> >>dependencies
> >> >> >like Batik, Velocity and Xerces?
> >> >> >
> >> >> >Pros:
> >> >> >* Since we resolve this dependency during build time, end users
> >>don't
> >> >>get
> >> >> >affected by Sourceforge downtimes
> >> >> >* If Sourceforge is down when we make the build, we just get the
> >> >> >dependency
> >> >> >from our previous good build. OSMF has not changed for a while
> >> >> >* Our Installer already has a way to force users to accept the
> >>license
> >> >>for
> >> >> >OSMF. So very little change required to the Installer.
> >> >> >
> >> >> >Cons (?):
> >> >> >* OSMF would have to be made a 'required' component instead of
> >> >>'optional'.
> >> >> >Since it is a small, single file, I don't think this is quite a
> >> >>problem.
> >> >> >* Installer needs to be reworked a bit, to eliminate the optional
> >>OSMF
> >> >> >download path. Should not be a major change.
> >> >> >
> >> >> >What do folks think of this proposal?
> >> >> >
> >> >> >Thanks,
> >> >> >Om
> >> >>
> >> >>
> >>
> >>
>
>
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Alex Harui <ah...@adobe.com>.
The set of required and optional steps for new installs is determined by a
config file. The FlexJS install, for example, doesn’t offer or install
OSMF. I think we can control everything from the config file and
installer.xml, which would be desirable for our Linux users anyway.
-Alex
On 10/9/14, 12:20 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Thu, Oct 9, 2014 at 12:15 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> Why do we need to change the installer? What part can’t be done in the
>> ant script?
>>
>
>Is it possible to stop OSMF download by just changing the installer.xml?
>
>I was also thinking about changing the wording from 'optional' to
>'required', and the multiple locale changes that would be required. I
>guess there is no need to change the Installer if OSMF is already a
>required component. Bottom line is that the Installer will not allow you
>to proceed until you explicitly select OSMF and agree to the MPL license.
>
>Thanks,
>Om
>
>
>>
>> On 10/9/14, 12:10 PM, "OmPrakash Muppirala" <bi...@gmail.com>
>>wrote:
>>
>> >On Thu, Oct 9, 2014 at 12:03 PM, Alex Harui <ah...@adobe.com> wrote:
>> >
>> >> No particular objection. Are you suggesting we go back and
>>re-release
>> >>all
>> >> previous releases or is this just for the future?
>> >>
>> >
>> >I think just for future. This requires a change to both the SDK
>>(release
>> >build script) as well as the Installer. It would be better if we make
>>a
>> >clean break from the past. So, this means that if someone wants to
>> >download Flex SDK verion equal to or lower 4.13, they need to use
>> >Installer
>> >3.1 or lower. For Flex 4.14 and higher, they need Installer 3.2.
>> >
>> >We have done the same exact thing in the past when we made TLF part of
>>the
>> >SDK and no one really complained about it.
>> >
>> >
>> >>
>> >> I¹m not sure OSMF is the main culprit for failed downloads. AIR was
>> >>more
>> >> likely to choke for me in recent testing.
>> >>
>> >
>> >From all the complaints we are receiving, it seems that fixing the OSMF
>> >question would bring a lot of stability to the Installer. Plus, I feel
>> >that the Adobe servers are a more resilient than the SourceForge
>>servers.
>> >
>> >Thanks,
>> >Om
>> >
>> >
>> >>
>> >> -Alex
>> >>
>> >> On 10/9/14, 11:52 AM, "OmPrakash Muppirala" <bi...@gmail.com>
>> >>wrote:
>> >>
>> >> >How about we download the OSMF swc during the release build stage
>>and
>> >> >package it with the SDK artifact like we do other third party
>> >>dependencies
>> >> >like Batik, Velocity and Xerces?
>> >> >
>> >> >Pros:
>> >> >* Since we resolve this dependency during build time, end users
>>don't
>> >>get
>> >> >affected by Sourceforge downtimes
>> >> >* If Sourceforge is down when we make the build, we just get the
>> >> >dependency
>> >> >from our previous good build. OSMF has not changed for a while
>> >> >* Our Installer already has a way to force users to accept the
>>license
>> >>for
>> >> >OSMF. So very little change required to the Installer.
>> >> >
>> >> >Cons (?):
>> >> >* OSMF would have to be made a 'required' component instead of
>> >>'optional'.
>> >> >Since it is a small, single file, I don't think this is quite a
>> >>problem.
>> >> >* Installer needs to be reworked a bit, to eliminate the optional
>>OSMF
>> >> >download path. Should not be a major change.
>> >> >
>> >> >What do folks think of this proposal?
>> >> >
>> >> >Thanks,
>> >> >Om
>> >>
>> >>
>>
>>
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Oct 9, 2014 at 12:15 PM, Alex Harui <ah...@adobe.com> wrote:
> Why do we need to change the installer? What part can’t be done in the
> ant script?
>
Is it possible to stop OSMF download by just changing the installer.xml?
I was also thinking about changing the wording from 'optional' to
'required', and the multiple locale changes that would be required. I
guess there is no need to change the Installer if OSMF is already a
required component. Bottom line is that the Installer will not allow you
to proceed until you explicitly select OSMF and agree to the MPL license.
Thanks,
Om
>
> On 10/9/14, 12:10 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >On Thu, Oct 9, 2014 at 12:03 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> No particular objection. Are you suggesting we go back and re-release
> >>all
> >> previous releases or is this just for the future?
> >>
> >
> >I think just for future. This requires a change to both the SDK (release
> >build script) as well as the Installer. It would be better if we make a
> >clean break from the past. So, this means that if someone wants to
> >download Flex SDK verion equal to or lower 4.13, they need to use
> >Installer
> >3.1 or lower. For Flex 4.14 and higher, they need Installer 3.2.
> >
> >We have done the same exact thing in the past when we made TLF part of the
> >SDK and no one really complained about it.
> >
> >
> >>
> >> I¹m not sure OSMF is the main culprit for failed downloads. AIR was
> >>more
> >> likely to choke for me in recent testing.
> >>
> >
> >From all the complaints we are receiving, it seems that fixing the OSMF
> >question would bring a lot of stability to the Installer. Plus, I feel
> >that the Adobe servers are a more resilient than the SourceForge servers.
> >
> >Thanks,
> >Om
> >
> >
> >>
> >> -Alex
> >>
> >> On 10/9/14, 11:52 AM, "OmPrakash Muppirala" <bi...@gmail.com>
> >>wrote:
> >>
> >> >How about we download the OSMF swc during the release build stage and
> >> >package it with the SDK artifact like we do other third party
> >>dependencies
> >> >like Batik, Velocity and Xerces?
> >> >
> >> >Pros:
> >> >* Since we resolve this dependency during build time, end users don't
> >>get
> >> >affected by Sourceforge downtimes
> >> >* If Sourceforge is down when we make the build, we just get the
> >> >dependency
> >> >from our previous good build. OSMF has not changed for a while
> >> >* Our Installer already has a way to force users to accept the license
> >>for
> >> >OSMF. So very little change required to the Installer.
> >> >
> >> >Cons (?):
> >> >* OSMF would have to be made a 'required' component instead of
> >>'optional'.
> >> >Since it is a small, single file, I don't think this is quite a
> >>problem.
> >> >* Installer needs to be reworked a bit, to eliminate the optional OSMF
> >> >download path. Should not be a major change.
> >> >
> >> >What do folks think of this proposal?
> >> >
> >> >Thanks,
> >> >Om
> >>
> >>
>
>
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Alex Harui <ah...@adobe.com>.
Why do we need to change the installer? What part can’t be done in the
ant script?
On 10/9/14, 12:10 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Thu, Oct 9, 2014 at 12:03 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> No particular objection. Are you suggesting we go back and re-release
>>all
>> previous releases or is this just for the future?
>>
>
>I think just for future. This requires a change to both the SDK (release
>build script) as well as the Installer. It would be better if we make a
>clean break from the past. So, this means that if someone wants to
>download Flex SDK verion equal to or lower 4.13, they need to use
>Installer
>3.1 or lower. For Flex 4.14 and higher, they need Installer 3.2.
>
>We have done the same exact thing in the past when we made TLF part of the
>SDK and no one really complained about it.
>
>
>>
>> I¹m not sure OSMF is the main culprit for failed downloads. AIR was
>>more
>> likely to choke for me in recent testing.
>>
>
>From all the complaints we are receiving, it seems that fixing the OSMF
>question would bring a lot of stability to the Installer. Plus, I feel
>that the Adobe servers are a more resilient than the SourceForge servers.
>
>Thanks,
>Om
>
>
>>
>> -Alex
>>
>> On 10/9/14, 11:52 AM, "OmPrakash Muppirala" <bi...@gmail.com>
>>wrote:
>>
>> >How about we download the OSMF swc during the release build stage and
>> >package it with the SDK artifact like we do other third party
>>dependencies
>> >like Batik, Velocity and Xerces?
>> >
>> >Pros:
>> >* Since we resolve this dependency during build time, end users don't
>>get
>> >affected by Sourceforge downtimes
>> >* If Sourceforge is down when we make the build, we just get the
>> >dependency
>> >from our previous good build. OSMF has not changed for a while
>> >* Our Installer already has a way to force users to accept the license
>>for
>> >OSMF. So very little change required to the Installer.
>> >
>> >Cons (?):
>> >* OSMF would have to be made a 'required' component instead of
>>'optional'.
>> >Since it is a small, single file, I don't think this is quite a
>>problem.
>> >* Installer needs to be reworked a bit, to eliminate the optional OSMF
>> >download path. Should not be a major change.
>> >
>> >What do folks think of this proposal?
>> >
>> >Thanks,
>> >Om
>>
>>
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Oct 9, 2014 at 12:03 PM, Alex Harui <ah...@adobe.com> wrote:
> No particular objection. Are you suggesting we go back and re-release all
> previous releases or is this just for the future?
>
I think just for future. This requires a change to both the SDK (release
build script) as well as the Installer. It would be better if we make a
clean break from the past. So, this means that if someone wants to
download Flex SDK verion equal to or lower 4.13, they need to use Installer
3.1 or lower. For Flex 4.14 and higher, they need Installer 3.2.
We have done the same exact thing in the past when we made TLF part of the
SDK and no one really complained about it.
>
> I¹m not sure OSMF is the main culprit for failed downloads. AIR was more
> likely to choke for me in recent testing.
>
>From all the complaints we are receiving, it seems that fixing the OSMF
question would bring a lot of stability to the Installer. Plus, I feel
that the Adobe servers are a more resilient than the SourceForge servers.
Thanks,
Om
>
> -Alex
>
> On 10/9/14, 11:52 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> >How about we download the OSMF swc during the release build stage and
> >package it with the SDK artifact like we do other third party dependencies
> >like Batik, Velocity and Xerces?
> >
> >Pros:
> >* Since we resolve this dependency during build time, end users don't get
> >affected by Sourceforge downtimes
> >* If Sourceforge is down when we make the build, we just get the
> >dependency
> >from our previous good build. OSMF has not changed for a while
> >* Our Installer already has a way to force users to accept the license for
> >OSMF. So very little change required to the Installer.
> >
> >Cons (?):
> >* OSMF would have to be made a 'required' component instead of 'optional'.
> >Since it is a small, single file, I don't think this is quite a problem.
> >* Installer needs to be reworked a bit, to eliminate the optional OSMF
> >download path. Should not be a major change.
> >
> >What do folks think of this proposal?
> >
> >Thanks,
> >Om
>
>
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Alex Harui <ah...@adobe.com>.
No particular objection. Are you suggesting we go back and re-release all
previous releases or is this just for the future?
I¹m not sure OSMF is the main culprit for failed downloads. AIR was more
likely to choke for me in recent testing.
-Alex
On 10/9/14, 11:52 AM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>How about we download the OSMF swc during the release build stage and
>package it with the SDK artifact like we do other third party dependencies
>like Batik, Velocity and Xerces?
>
>Pros:
>* Since we resolve this dependency during build time, end users don't get
>affected by Sourceforge downtimes
>* If Sourceforge is down when we make the build, we just get the
>dependency
>from our previous good build. OSMF has not changed for a while
>* Our Installer already has a way to force users to accept the license for
>OSMF. So very little change required to the Installer.
>
>Cons (?):
>* OSMF would have to be made a 'required' component instead of 'optional'.
>Since it is a small, single file, I don't think this is quite a problem.
>* Installer needs to be reworked a bit, to eliminate the optional OSMF
>download path. Should not be a major change.
>
>What do folks think of this proposal?
>
>Thanks,
>Om
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by Alex Harui <ah...@adobe.com>.
On 10/9/14, 12:04 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
>I just realized that OSMF is already a 'required' component. So ignore
>this point.
I was surprised by this as well. I¹m not sure if that is true for the
binary package.
IMO, if you are not using Spark Video, it shouldn¹t matter if that SWC is
there or not.
Also note that OSMF is MPL and not AL like Batik and Velocity, but I think
we can still bundle it if we want to as long as we don¹t bundle the source
for it.
-Alex
Re: Solution to OSMF/Sourceforge problem with Installer
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Oct 9, 2014 at 11:52 AM, OmPrakash Muppirala <bi...@gmail.com>
wrote:
> How about we download the OSMF swc during the release build stage and
> package it with the SDK artifact like we do other third party dependencies
> like Batik, Velocity and Xerces?
>
> Pros:
> * Since we resolve this dependency during build time, end users don't get
> affected by Sourceforge downtimes
> * If Sourceforge is down when we make the build, we just get the
> dependency from our previous good build. OSMF has not changed for a while
> * Our Installer already has a way to force users to accept the license for
> OSMF. So very little change required to the Installer.
>
> Cons (?):
> * OSMF would have to be made a 'required' component instead of
> 'optional'. Since it is a small, single file, I don't think this is quite
> a problem.
>
I just realized that OSMF is already a 'required' component. So ignore
this point.
> * Installer needs to be reworked a bit, to eliminate the optional OSMF
> download path. Should not be a major change.
>
> What do folks think of this proposal?
>
> Thanks,
> Om
>