Will the install result in a workspace set up exactly like Mike's?
http://www.youtube.com/watch?v=b0AGiq9j_Ak
Seriously though, there could be some benefit in that.
Tim Worman
UCLA GSE&IS
On Oct 10, 2010, at 9:48 AM, David LeBer wrote:
>
> On 2010-10-10, at 12:17 PM, Jeremy Matthews wrote:
>
>> Ah - cool.
>>
>> There are some things I like about this, and somethings which I would consider changing (IMHO).
>>
>> Pros
>> - "Always" Up-to-date (which is really, mostly, always)...much nicer than have a script on a server continuously generate packages
>> - Simplicity (big for me)
>>
>> Cons
>> - Need to be online during installation (some folks download packages and then run, or are not constantly connected)
>> - Not a typical installation package (which, as an IT guy, drives me just a little crazy)
>> - No continuous feedback (though probably easily solved if using cocoa API's like NSURL), like with a simple progress bar
>>
>> Questions
>> - Is connectivity checked before attempting the download?
>> - Is the download file md5 hash checked before download?
>> - Are there alternate links in case the primary download URLs fail?
>> - Is there a "Cancel" button?
>
> Yes
>
>> - Are we using API's such as NSURL, or running NSTask?
>>
>> In the past, I create packages (using packagemaker) which contained a new feature (Package References) - so the package would download components remotely during the install process. We found this confused the users and frustrated support staff. I thought it was cool, and basically the future...since we're rapidly heading to a space where everything is connected, always. I suppose we're not quite there yet since every client and business, save a few enterprise groups, that told me to change it back).
>>
>> I'm really interested in what everyone else thinks here....should we shelve the turnkey in favor of something like this?
>> Not wanting to devote time to spend on yet another installation solution...we already have a few now, and I think we need to choose one (maybe two) which will be the future "newbie" installer....need to get rid of the confusion there.
>
> This is just a simple Cocoa wrapper around Mike's shell script. As such it simply derives the appropriate download path and then calls through to an embedded version of the script with NSTask.
>
> It is not designed to be a replacement for anything, and to be completely honest, I have no interest in creating or supporting the next great installer. Mike's script is just really cool, and I wanted to make it easier to use. I have a wickedly fast internet connection right now, so I can have a complete eclipse install up and running in about 3 minutes. Which is awesome BTW.
>
> I might consider enhancing Mike's script so it takes a second optional eclipse archive location, so you can grab from a local archive for the eclipse app itself, but that is probably the extent of my planned enhancements.
>
> That said, I'll probably also push this up to github for those who want to extend it themselves.
>
>
>>
>> Thanks,
>> jeremy
>>
>> On Oct 9, 2010, at 10:55 PM, David LeBer wrote:
>>
>>> Based on Mike's wolips install script:
>>>
>>> <http://gist.github.com/610081>
>>>
>>> I whipped up a thin cocoa wrapper for the command line challenged in our ranks.
>>>
>>> Demo here:
>>>
>>> <https://files.me.com/dav1d/wxajka.mov>
>>>
>>> Let me know if you are interested in testing it.
>
> ;david
>
> --
> David LeBer
> Codeferous Software
> 'co-def-er-ous' adj. Literally 'code-bearing'
> site: http://codeferous.com
> blog: http://davidleber.net
> profile: http://www.linkedin.com/in/davidleber
> twitter: http://twitter.com/rebeld
> --
> Toronto Area Cocoa / WebObjects developers group:
> http://tacow.org
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-de..ists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/lists%40thetimmy.com
>
> This email sent to list..hetimmy.com
This archive was generated by hypermail 2.0.0 : Sun Oct 10 2010 - 19:22:22 UTC