Ate Douma wrote:
>
>
> 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 :-)
The last line of my comment can be scraped. I had a similar problem with the
mevenide plugin which download zipfile also didn't had the feature.xml and
plugins jarred. I incorrectly referred to that one and is improper for your plugin.
Sorry if I caused any confusion because of this.
>
> 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
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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:23:28 2004