Latest @ 
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fwrite_16x16.gif)
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fcheck_16x16.gif)
Forum Controls
Spotlight Features
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.javalobby.org%2Fimages%2Fspotlight%2Fdi_heritage.gif "The Rich Engineering Heritage Behind Dependency Injection")
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fwrite.gif "Reply to this Thread")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fhome.gif "Home")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Ffolder_up.gif "Up to Thread List")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fnext_thread_off.gif "No Next Thread")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fnext_messages.gif "Next Page of Replies")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fprev_messages_off.gif "No Previous Replies")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fprev_thread_off.gif "No Previous Thread")
![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fwrite_off.gif "No Email this thread to a friend")
You are viewing a mobilized version of this site...
View original page here
Making the UpdateManager a better place
At 5:50 AM on Sep 1, 2006, Stefan Langer
wrote:
There are quite a few issues with it among which are:
Why is there a difference between choosing to install a new feature and updating an old one? Shouldn't both be done through the same UI?
Why can't one choose a dedicated mirror which sticks around more easily than having to define some obscure update policy?
Why can one only install a feature but not look for a specific plugin to update? Dependency resolving included.
Improvement is greatly needed and while we are at it I think there is room to integrate new features that would increase the usability and make the updatemanger a central not wanting to miss feature of the plattform.
This brings me to the reason I'm posting this thread as I want to bring the attention to bug #142879 which is an enhancement request to integrate EPIC as a central plugin repository into the eclipse plattform. I invite everyone to comment on it (and vote for it ) either here or by means of the bug discussion above.
If anyone knows of other bugs that are related to the UpdateManager feel free to list them here as well so people can vote.
So to come to a conclusion what do you think?
Is a central plugin repository (EPIC) needed? Should EPIC be the place that does it?
How would you like such a repository included into the Plattform?
17 replies so far (![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.eclipsezone.com%2Fimages%2Fstd%2Ficons%2Fwrite_16x16.gif "Reply to this Thread")
Post your own)
Re: Making the UpdateManager a better place
I've been complaining about it for some time, too. It also came up on making Eclipse better elsewhere on this forum.In particular, this sounds very related (but not a duplicate) of the bug I raised: bug 126732 . We should be getting rid of features, and just dealing with bundles, and the update manager shouldn't look at features, it should look at bundles. Once you've got that out of the way, then making a bundle-oriented (as opposed to feature-oriented) repository is a no brainer.
I also proposed that a bundle-oriented repository should use an Atom feed as its structure; that way, it's readable both by humans and also by computers. Plus, it standardises things like titles, update dates, etc. and you can then use standard libraries to query new entries, or use mechanisms to upload information. Although not well known, an Atom feed can contain any type of information (either XML or appropriately textually encoded), and an atom feed doesn't have to contain all the atom entries (an atom entry is defined as a top-level type). They would be able to replace site.xml, since it would then be an atom feed, and each bundle(version) could declare its own atom entry.
Please vote for both these bugs:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=127236
https://bugs.eclipse.org/bugs/show_bug.cgi?id=126732
(I've put them as dependencies on this one; it seems like once the update manager works at a bundle level, integrating it into EPIC seems like the sensible next step; please, feel free to add comments and/or disagree though)
Alex.
Re: Making the UpdateManager a better place
Most annoying thing for me is not being able to uninstall a plugin. When I want to try a new plugin I usally create a new Eclipse installation, copy my workspace to somewhere else and try the plugin there. Which most of the time makes me avoid trying it.Re: Making the UpdateManager a better place
I would like an update manager that-does its thing without me clicking ok/next multiple times (are you sure you want to install this 100MB foo which you just spend half an hour waiting to download for and of which already approved the license? Duh!)
-that doesn't hide its most used options several dialogs/menus deep
- that can download and apply updates without more than one OK click.
- is a little smarter about remembering settings (e.g. the mirror setting).
- does not fail without providing a retry option (quite frustrating, especially with the above unfixed)
Re: Making the UpdateManager a better place
But this is only true if you haven't installed the plugin via update site or if you have upgraded which is quite annoying I agree.Considering the structure of the plugin directory it should be possible to uninstall a plugin completly and all its unneeded dependencies without having a install history.
Maybe a nother bug?
Re: Making the UpdateManager a better place
Especially the retry would be great to have. But I'm not quite sure if it is possible to do this with every http connection? I don't have the HTTP spec remembered but does it allow chunked tranfser or is there a special extension needed?Re: Making the UpdateManager a better place
I agree and voted on bothI especially find the idea compelling of giving an updatesite as an atomfeed. Once we are bundle based this could allow for special patch downloads. This would of course need some sort of bundle patch thing.
Re: Making the UpdateManager a better place
> Considering the structure of the plugin directory it> should be possible to uninstall a plugin completly
> and all its unneeded dependencies without having a
> install history.
That is true. I can delete the plugins and features manually, if I know exactly which ones are they. But then I could use vi instead
Re: Making the UpdateManager a better place
There's a couple of things here:Restartable downloads. HTTP does permit this; (see section 3.12 and 4.15 of RFC 2616 (HTTP/1.1) ). However, the UpdateManager can fail when all but one resource is available
(http://www.eclipse.org/plugin1.jar 100% OK)
(http://www.eclipse.org/plugin2.jar 100% OK)
(http://www.eclipse.org/plugin3.jar fails)
In this scenario, plugin1.jar and plugin2.jar are thrown away, and re-downloaded from the source, despite the fact that they've already been fully downloaded once before.
The second scenario, where 50% is downloaded, could be achieved by restartable download. However, the server (and any intermediate proxies) have to be HTTP/1.1 compliant to achieve this goal.
What's worse is that you may get redirected to a proxy that doesn't mirror all of the Eclipse stuff (e.g. doesn't host the WTP, for example) and thus gives you a 404. It would be sensible in these cases, if http://www.eclipse.org/plugin3.jar gives 404, that it then automatically tries http://mirror.eclipse.org/plugin3.jar at least once before giving up with an error message.
Alex.
PS I know those aren't the real URLs for plugin1 ...
Re: Making the UpdateManager a better place
> > Considering the structure of the plugin> directory it
> > should be possible to uninstall a plugin
> completly
> > and all its unneeded dependencies without having
> a
> > install history.
>
> That is true. I can delete the plugins and features
> manually, if I know exactly which ones are they. But
> then I could use vi instead ;)
I don't quite agree on the vi part
Re: Making the UpdateManager a better place
It would be at least a step in the right direction if at least the updatemanager would keep fully downloaded plugins in place. Most features now are made up of several smaller plugins which are not as big so if you wouldn't have to download the fully loaded once again you would allready save a lot of bandwidth. Now this brings as again to the request that bundels should be updateable and not only features.Re: Making the UpdateManager a better place
> I don't quite agree on the vi part ;)You must be an emacs guy
> it should be possible for the updatemanager
> /configmanager to uninstall a plugin and its unneeded
> dependencies automatically without having been
> installed via an update site.
Until you say that, I wasn't aware that I can uninstall/disable a plugin that is installed from the update manager. I think the menu sequence is not self explanatory :"Help"->"Software Updates"->"Manage Configuration"
I think the best solution would be having a standard plug-in(or bundle) package format and disallowing manual plug-in installation(ie: copying over eclipse directories)
This could give a better offline installation experience and allow easy developing of third-party plugin(or bundled eclipse) installers.
This way it would also be easier to support multi-user unix installations (this was under discussion in another thread) by giving an option to install as a global or local plug-in.
Re: Making the UpdateManager a better place
I agree to most of what has been said here, the updatemanager needs a serious makeover.Ideas i especially like are the atom-feed and to get rid of features a. A central repository for plugins is also one of the things i miss on a day to day basis.
But i don't think that eclipseplugincentral.com provides a sufficient base, its layout is just horrible. Even tough its halfways abandoned, i still prefer eclipse-plugins.info because of its simple interface and it just feels more 'open'. I can't really say why, but epic feels 'commercial' all over , and thats not really eclipseish in my eyes.
regards,
Dominik
Re: Making the UpdateManager a better place
If you like the idea of an atom feed as an update site, vote for the bug 127236 . This is one area in which I think Eclipse can lead the way in showing how to do it for other companies, but unfortunately there seems to be little interest amongst the Eclipse committers to work on (perhaps, because it's not that sexy to implement).The only way it will happen is if we can show Eclipse that enough people want that feature, and that will only happen with people voting for it...
Alex.
Re: Making the UpdateManager a better place
> [...]> But i don't think that eclipseplugincentral.com
> provides a sufficient base, its layout is just
> horrible. Even tough its halfways abandoned, i still
> prefer eclipse-plugins.info because of its simple
> interface and it just feels more 'open'. I can't
> really say why, but epic feels 'commercial' all over
> , and thats not really eclipseish in my eyes.
> [...]
I think EPIC as a platform would make a great central point as an eclipse pluing repository since it is actually managed by the foundation unlike eclipse-plugin.info. The layout is just a view onto the repository and I think there can be improvement there as well. But for starters it would be great if there is a central repository location under foundation control which is searchable for plugins and provides the means to download the found plugins via the update manager.
I think the key here is that it has to be under foundation control in order to be accepted by the whole community and this includes commercial vendors.