My good cyber-friend Scott McPhee has posted a mini-rant The burning smell of fail that is the Eclipse 3.4 software updater on his blog, and we spent a bit of time discussing it over at Straight-Talking-Java.
Let me say at the outset that his headline point is completely correct. The P2 update manager included with Eclipse 3.4 did have a distinct acrid rubber odor. I just tried 3.4.2 and it works better, but its still no fun. Believe it or not, P1 was actually worse. But Scott's implied take-away, that the P2 model is fundamentally broken, and that a policy driven approach would solve everything, is completely wrong.
(Note my combative use of language above. Scott has been bragging on his blogging traffic and I'm going on the theory that controversy sells!)
I'm actually the last person who thought he'd find himself defending P2. For an Eclipse user like Scott, a broken update process is an annoyance, but he can always switch to a different tool. For an Eclipse plugin developer it can be a nightmare, because updates mean that those users that get frustrated and give up never get to see your toolset. Of all of the feedback I've received on my software the number one issue has been installation. I've spent an enormous amount of time building, testing and diagnosing update site issues, under an ever evolving set of PDE build tooling approaches and update site dependencies. Two years mucking around with builds and tests and I always ended up needing to do important parts manually. I dread putting out new releases. And I've spent weeks putting together detailed instructions and screenshots simply going over installation issues. "If this doesn't work, try this. If all else fails, do this."
Now, normally I would have simply bitched incessantly to anyone who would listen -- just as we all do when we encounter some piece of software that bugs us and we don't feel like we can do anything about it. But I rely on P2 and more importantly this isn't Microsoft Vista we're talking about. Eclipse is fundamentally solid and I had submitted enough bug reports to know that non-contributors are taken seriously. And the P2 team was making a heroic effort to get things right. I first noticed this reading a post that fellow ST-J'er Eric Rizzo made to the list, pointing to a page where the P2 team was soliciting feedback on UI improvements. So rather than shout at my monitor I tried something different. Almost as an experiment, I contributed a few ideas to the user scenario mix just to see if they would stick. Soon after there were real live bugzilla entries in for the UI Use Case scenarios, and I found myself throwing in more thoughts. It was still a bit of a surprise to see that my feedback and that of others had an impact. This kind of openness to criticism and different perspectives was a bit hard to swallow at first. Most of us have had the experience of giving feedback on software only to have it met with lip service or even open hostility.
Fast forward a couple of months. (Yes, I said months, not years.) You know what? After a few days work -- thanks to some major improvements in PDE build -- I put together a completely automated headless build for a set of tools with complex features and 20+ plugins.
Then I did a test release and the update process went flawlessly. I keep expecting the appearance of an indecipherable dialog box and the sinking feeling that goes with it, but it never happened. I've also used all kinds of plugins from various sources -- again, no problems. And the UI actually makes sense now! I don't need to walk my users through a seemingly arbitrary set of steps. Don't believe me? I've made a little demo of the install process for my plugins -- check it out.
The point of all of this is not just to say that the Eclipse P2 team did a great job and that the Update Manager deserves a new look. They did, and it does. And a lot of the improvements would have been made without community input.
But the most impressive aspect of all of this was the way in which project developers actively sought community input and facilitated that using innovative, lightweight -- and dare I say courageous? -- practices. It was a stretch for the team to put a few pages on a Wiki page and expect the broader Eclipse community to respond. And it was a stretch for users to respond and trust that their suggestions wouldn't go straight to the "not-invented-here" box. But it worked, and they should be proud.
So give it a try Scott, and let us know what you think.
Update
Eric mentioned in a comment below that I could use an associateSites.xml file to specify the dependencies my plugins have on other sites. I've been trying to find a way to do exactly that but had given up for the time being and sort of assumed that the current P2 setup didn't support that.
So I added the file -- you need to add an associateSitesURL attribute to the site.xml as well, but it didn't make any difference. Remember that site.xml is a P1 construct, so P2 only uses it to infer information for the new style update sites. Well, P2 already does a good job of finding dependent ("discovery") sites from the feature.xml files, so those sites were already appearing in the context.xml file. Adding associate sites only created duplicates. See this wiki for more information than you probably want to know on this subject. Taking a close look at that, and doing a little more experimentation I discovered that the sites were being actually being added, but they were disabled by default. Huh?
But no problem; you can re-enable the sites by setting repository attribute options="1". After making this change, I was able to create an install that only requires the user to add one URL and then select the MetaABM features. Cool! I'll post an updated screencast tomorrow and Scott, this time I'll try to get the sound-levels right!
The only downside to all of this is that I can no longer say that the build is completely automatic. There are four characters I need to change manually in the content.xml file. I briefly mucked around with trying to figure out a way to get these set differently. But you know, sometimes you've just got to learn to leave well enough alone.
Update 2
Thanks Eric and Scott for your really helpful critique of the movie and install process. Seriously. Based on that I went back to work and now I've updated the Installation Movie now. Can anyone really complain that that was too complicated?
Tuesday, April 21, 2009
Subscribe to:
Post Comments (Atom)
Popular Posts
-
I'm happy to announce that the Virgo Tooling M4 release is available. If you just want to find out more about that, skip ahead to the sectio...
-
Every once in a while I think it makes sense to have a completely on-topic, technical post! One of the (many) things that has been on the ...
-
“So the final lesson of 1918, a simple one yet the one most difficult to execute, is that those who occupy positions of authority must lesse...
-
I've been meaning to start a blog for some time now (years) and the birth of our baby seemed like an especially auspicious time. So welcome ... -
I've been spending quite a bit of time lately playing with the EEF framework. C'est magnifique! (No, I don't actually know any french, but I... -
Just a quicky here.. I like to use views instead of editors for most of my GEF viewers. They are a lot of advantages to views -- the most s...
-
Many of us who've spent time traipsing through the Eclipse wilderness are probably familiar with this story... Tis a beautiful, sunlit 'mo...
-
Every once an a while, a new way of thinking comes along that is so powerful, so unique, so practical -- just so damn cool, really -- that i... -
OK, I am long over-due for an update to the blog, and I have lots to report on, but I've been deep in build hell for the last week, (and the... -
When Butterflyzer was launched a year ago it was introduced with the following words: "Butterflyzer is in Alpha now. Before we release mor...
I watched the video (the audio level is very low BTW) and ... well ... here's my critique (which means of the update system, not your plugin).
ReplyDelete1. First, you had to put three update sites in.
2. Then you had to select a whole bunch of miscellaneous plugins. Or at least two. One of which was optional. Apparently.
3. When you expanded the MetaABM site look at all those options! It's ok for you, know know *exactly* which one you want. I don't have the knowledge of the plugin author and a lot of those options, what do they even mean?
4. compare and contrast to 'apt-get install metaabm' -- all the dependencies managed automatically.
5. you know what this all means to me as a user? I don't bother to install plugins anymore except for the ones I absolutely have to have (Subclipse and that's about it).
6. this thing looks like to me that it is still totally designed from the plugin developers perspective. I use p2 once every three months, i don't really see the time spent with it as productive, it's waste - and i want to minimise waste. every second i spend using p2 makes me believe that the designers of the mechanism have not considered my use-case (the majority of eclipse users who focus on eclipse as a tool to get some other programming task done and not as a 'platform' or 'ecology' they want to 'explore') **at all**.
7. there are two things stopping me ditching eclipse. 7.1: intellij costs money, and has the most retarded key bindings on the planet. 7.2 ... see 7.1.
Indeed, the p2 team should be applauded for their openness.
ReplyDeleteI actually think your video demo might have more steps than necessary; couldn't you have used an associateSites XML file in your own update site instead of manually entering the OAW and other site?
Hmm.. it looks like the repository association stuff is still a bit in flux. see: http://wiki.eclipse.org/Equinox/p2/Repository_Association I've been trying to figure out a good way to handle this under P2 without forcing users to enter dependent repos manually. I'm going to play with this and then I'll post an update.
ReplyDeleteA lot of Scott's critiques are based on my poor production value; I'll accept that!
ReplyDelete1. Yeah, that's the one annoyance. But its a double-edged sword; you don't want to invisibly force the user to use a specific source for dependencies when that dependency can change and the related plugin vendor may have change the location. Still I agree that there needs to be a way to handle this.
BTW, now that MetaABM is becoming part of Eclipse project and the OpenArchitectureWare is as well, there will be only one external dependency to worry about and that one is optional.
2. True. If I can solve 1, then that issue will be solved as well.
3. You don't need to expand the site, you could easily just select the top-level items.
4. That assumes that the dependencies can be managed separately. But again, it looks like 1 is the remaining issue to be solved here.
5. I don't see how this one follows. If you want to download a piece of software, you don't mind typing a URL into a browser, do you?
6. I don't get this objection. If you want to use say the Python Development Tools then what's wrong with selecting a simple menu item, going down a list, selecting PDT and then clicking install? That seems to be about as straightforward as it can get.
7. Actually the hardest part of adopting Eclipse for me was to give up all of the IntelliJ bindings that had become second-nature.
Miles, just re: 5 and 6.
ReplyDeletefirst, typing in a url is a transient affair, it's not adding the url to the system before you can use it. it's more akin to having to bookmark a url and then select the bookmark! I don't bookmark anything anymore - except for stuff in delicious - because usually I remember the URL or part of it (e.g. 'cnn') and that's all I need to type - the browser fills in the rest.
off a website there is usually text that guides me to the link i want to click to get to somewhere I want to. some plugins - and this is the fault of the plugin authors in this case - just have a bunch of cryptic entries and i find i have to go back to the website and work out which feature i want.
maybe the p2 team is fantastically open and all is good. this doesn't change the fundamental critique i have of the system design. which hasn't changed from the old way of doing things to teh new one. i just don't find it intuitive or - especially - easy to use in any way.
the clincher for me is the ubuntu - and now i think of it - maven - systems of managing dependencies and performing local installations. it seems to me that ubuntu has an excellent working system to manage complex interrelationships and it's brilliant! I don't find the eclipse system in anyway brilliant, and over the years it's hardened my heart to installing eclipse plugins - i simply don't do it anymore unless there's there is a definitely enormous benefit.
VX sez..
ReplyDelete""first, typing in a url is a transient affair, it's not adding the url to the system before you can use it. it's more akin to having to bookmark a url and then select the bookmark! I don't bookmark anything anymore - except for stuff in delicious - because usually I remember the URL or part of it (e.g. 'cnn') and that's all I need to type - the browser fills in the rest."Well a couple of thoughts there. First, installing a significant piece of software is a bigger deal than just going to a web page so its not unreasonable for the P2 team to now spend time say parding the url, adding ".com" and "http://" and so on. Second and most importantly, you want to keep the URL around -- you certainly don't want to enter it every-time you need to update software or add a new component for example.
""off a website there is usually text that guides me to the link i want to click to get to somewhere I want to. some plugins - and this is the fault of the plugin authors in this case - just have a bunch of cryptic entries and i find i have to go back to the website and work out which feature i want.""Exactly; its the fault of the plugin authors for not providing good meta-data. Now, you can always simply select the top-level and get everything, but many many sites have a lot of features that are really different offerings; for example, not all of my users will want to install repast simphony which is a huge package in itself and includes groovy. I want to give them the option.
I'm not sure how much more guidance one needs. Presumably someone goes to say a Python tools site because they want some sort of Python tools, and they should be able to look at a list and decide what they want. This is no different from say Apple Software Update, where you can decide what you want and don't want to update.
This gets down to what I frankly don't get about the objection you and Scott raise. Yeah, I can understand that people hate when the process doesn't work. But I think that there is a fundamental misunderstanding here. Eclipse is not in control of the plugins that people can install nor would we want them to be! If say could only install Eclipse "blessed" software, people would scream bloody murder.
Given that, for external sites, Eclipse needs to elicit two pieces of information from the user: what the user wants and where he or she wants to get it.
OTOH, if all you want is Eclipse project plugins, you don't have to do anything. Just select all avialbe sites and go through a (very clear) list and select those components you want. You really need to look at the User story here. This is not designed primarily for us -- i.e. people who care about complex dependencies ala Maven. Its for people who simply want to locate some software they want and install it.