Mark Phippard wrote:
> Ate Douma <ate@douma.nu> wrote on 08/03/2004 06:26:50 AM:
>
>
>>What I also would like to see is a new site download tgz as at the
>
> company I
>
>>work doesn't have internet access at the work place.
>>We now use our own local update site.
>>The current site zip though still contains the invalid feature
>
> definitions with
>
>>the embedded " inside the id attribute:
>>id="org.tigris.subversion.subclipse.win32"0.9.12"Subclipse".
>>I already posted a request in the user list if the site tgz could be
>
> fixed but
>
>>received no response on it yet.
>>
>>I've already corrected it myself for now but needed other corrections
>
> also for
>
>>which I like to ask if these could be made to the official release so we
>
> don't
>
>>have to do those again next time.
>>
>>The whole idea of the site tgz is allowing it to be used offline using
>
> your own
>
>>local update site.
>>But, the site.xml and the feature.xml definitions still contain update
>
> url
>
>>definitions pointing back to http://subclipse.tigris.org/update. As
>
> result of
>
>>these, after an initial installation eclipse will try to look for
>
> updates there
>
>>the next time (leading to irritating error dialogs).
>>As far as I see it this is not needed at all. Can't those update url
>
> definitions
>
>>not just be removed from the site.xml and the feature.xml (as I had to
>
> do myself).
>
>>By default, eclipse will search for the plugins etc. relative from the
>
> site.xml
>
>>location which still be http://subclipse.tigris.org/update if updating
>
> online,
>
>>or from our local update site as we use it.
>>Thus, removing those update url definitions doesn't bring anything other
>
> than
>
>>requiring manual hacking if you need to use your own update site.
>>Only when an update site has to be moved like it was from looney to
>
> tigris a few
>
>>weeks ago this *is* a useful feature I think.
>>
>
>
> I do not think this is true. If it is, then it is a new change that I
> have missed. If you do not supply an update site URL in your feature.xml
> then Eclipse will not check for updates for that plugin. You would always
> have to do it manually.
>
> Mark
>
You are correct I think. We only tested it using manual updates. Meanwhile, I
found out how to use the update policy of the update manager which solves the
url problems (using a local proxy).
So please forget about the url issues and keep them in as required. Having the
feature.xml and plugin files jarred in future updates will be enough :-)
Regards,
Ate
>
> _____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
> _____________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: dev-help@subclipse.tigris.org
>
>
>
>
Received on Wed Aug 4 00:18:36 2004