Bugzilla – Full Text Bug Listing
| Summary: | Proposal: Eclipse downloadable plugins file format | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Zviki Cohen <zvikico> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | caniszczyk, contact, dann, Ed.Merks, henrik.lindberg, irbull, jboehme, jeffmcaffer, mn, overholt, pascal, peter, peter, remy.suen, thomas, yevshif |
| Version: | 3.6 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 178927 | ||
| Bug Blocks: | |||
|
Description
Zviki Cohen
I have always wanted a mechanism to trigger Eclipse from a web link, or a file. Not just for the purpose of installing something. I think it is far better to be able to tell Eclipse to install something from someplace than to invent a new plugin format. I.e. a small "eclipse script" is downloaded, when invoked, it will tell Eclipse to do the work. (In reply to comment #1) > I have always wanted a mechanism to trigger Eclipse from a web link, or a file. See bug 246628. Another idea we've kicked around in the past is simply using a content.xml file to describe what is desired, and ensuring that the necessary artifact locations are described there. You can imagine a user selecting a group of things they have installed and exporting this little file so that someone else could install it. "Here's my favorite stuff." In Bug 223264 we kicked around ideas for fast-paths that would skip the install wizard and simply do the install. Easing the installation has always been discussed - Web triggered install (bug #246628) - Installation description file / install folder (bug #225344), which this bug is likely a dup of. - Also the marketplace.eclipse.org team is looking for ways to make it easy for ppl to install software and as part of this effort they are also exploring a marketplace client. - Runnable plug-in format like you are suggesting ( I swear there use to be a bug about this) - Drag and drop of a file over the UI (see meeting minutes from the early days of p2) Now as for the specific aspect of double clicking on a file, we will first be blocked by #178927 which is flagged helpwanted. The other thing to not forget about all that is ease of adoption, who is going to produce these files, how much maintenance is there, can I use those as part of the build, .. And finally above all, the adoption of anything new at eclipse is slow (not a lot of teams have started providing p2 metadata, and a lot simply just produce zips of plug-ins). All that said, if anyone is willing to work on this from the community, we will try our best to help. (In reply to comment #1) > I have always wanted a mechanism to trigger Eclipse from a web link, or a file. > Not just for the purpose of installing something. I think it is far better to > be able to tell Eclipse to install something from someplace than to invent a > new plugin format. > > I.e. a small "eclipse script" is downloaded, when invoked, it will tell Eclipse > to do the work. Agreed, no wheel invention is required. However: 1. we do need a very simple installation mechanism. 2. I personally think downloading an archived site will be quicker and simpler. People don't like online installers. The current P2 tools (especially the director) makes it difficult to programatically install a plugin in a fully controlled manner, so leaving this to a separate install script means every developer will have to reinvent it. (In reply to comment #2) > (In reply to comment #1) > > I have always wanted a mechanism to trigger Eclipse from a web link, or a file. > > See bug 246628. Web installs are completely different. Again, many (most?) users don't install right away. People download and install later. The web-install is missing the point (though it will be nice, kind of like the old DC Magnet Links). (In reply to comment #3) > Another idea we've kicked around in the past is simply using a content.xml file > to describe what is desired, and ensuring that the necessary artifact locations > are described there. > > You can imagine a user selecting a group of things they have installed and > exporting this little file so that someone else could install it. "Here's my > favorite stuff." > > In Bug 223264 we kicked around ideas for fast-paths that would skip the install > wizard and simply do the install. It is OK, as long as you can double-click the file in the Explorer/Finder and invoke the installation. In must be that simple. Add the ability to package inside an archived site and... that's it :-) (In reply to comment #4) > Easing the installation has always been discussed > - Web triggered install (bug #246628) > - Installation description file / install folder (bug #225344), which this bug > is likely a dup of. > - Also the marketplace.eclipse.org team is looking for ways to make it easy for > ppl to install software and as part of this effort they are also exploring a > marketplace client. > - Runnable plug-in format like you are suggesting ( I swear there use to be a > bug about this) > - Drag and drop of a file over the UI (see meeting minutes from the early days > of p2) > > Now as for the specific aspect of double clicking on a file, we will first be > blocked by #178927 which is flagged helpwanted. > > The other thing to not forget about all that is ease of adoption, who is going > to produce these files, how much maintenance is there, can I use those as part > of the build, .. And finally above all, the adoption of anything new at eclipse > is slow (not a lot of teams have started providing p2 metadata, and a lot > simply just produce zips of plug-ins). > > All that said, if anyone is willing to work on this from the community, we will > try our best to help. It has always been discussed, yet the promised land is not in sight. So, I'm offering something which really can't be simpler. Having the user double-click a file or drop a file in a folder is two completely different concepts. Hence it is not a dup. Historically, the software installation gets a remake on every single major version (3.3, 3.4, 3.5). There's a reason for that and that means people understand it is an Achilles heal which needs improvement. It means resources are invested in this area. If this area is going to see improvements in 3.6, I think this should be on the table. >It has always been discussed, yet the promised land is not in sight.
This is true and this is because this is not priority for any of the current contributors.
Do you have a concrete plan?
(In reply to comment #9) > >It has always been discussed, yet the promised land is not in sight. > This is true and this is because this is not priority for any of the current > contributors. > Do you have a concrete plan? Reading your answer is really putting me off. What I'm actually reading is: please don't come with any suggestions unless you are willing to invest in implemeting them yourself (or at least find the people that will implement them). As I mentioned, it was on the table for Eclipse 3.3, 3.4 and 3.5. Which means it was a priority. All I'm asking: if it is still on the table for 3.6, please consider this as an alternative to yet another rewrite of the installation dialog box. You are interpreting too much. Let's recap. You are suggesting that we should be implementing this as part of 3.6 because it is important (note that the number of vote is still 0), and I'm telling you that we are not implementing this for this release. Consequently because it is an open source project and this idea seems to be close to your heart, I'm asking you if you want to contribute. All I'm saying is that you could be more receptive when it comes to feedback from the community. There are many ways to contribute. Coding is a major path, but it is not the only path. Opening issues are writing articles is also contribution. I do it because I care. I do it because I want Eclipse to be a better product and a better platform. As a major contributer for Eclipse, I am sure you want the platform to be successful and have a broad appeal. My voice is the voice of independent commercial plugin developers. You want us around. Where would the iPhone be without 3rd party apps? (In reply to comment #12) > All I'm saying is that you could be more receptive when it comes to feedback > from the community. > > There are many ways to contribute. Coding is a major path, but it is not the > only path. Opening issues are writing articles is also contribution. I do it > because I care. I do it because I want Eclipse to be a better product and a > better platform. As a major contributer for Eclipse, I am sure you want the > platform to be successful and have a broad appeal. My voice is the voice of > independent commercial plugin developers. You want us around. Where would the > iPhone be without 3rd party apps? Pascal is trying to walk the line most open source developers do. We like people to contribute but get frustrated when no one does. It's easy to ask for things, and yes bugs do help. In the end, Eclipse is a community of mutual self interests ;) There's been calls in the past for people to contribute to p2 with help of the p2 team: http://lenettoyeur-on-eclipse.blogspot.com/2009/08/p2-community-contribution.html http://lenettoyeur-on-eclipse.blogspot.com/2009/05/p2-call-for-community-testing.html http://wiki.eclipse.org/Equinox_p2_3.6_contributions One opportunity is to do a Google Summer of Code project next year on this. Another possibility is someone coming forward and working on this because it's important to them. That's my two cents. (In reply to comment #13) > Pascal is trying to walk the line most open source developers do. We like > people to contribute but get frustrated when no one does. It's easy to ask for > things, and yes bugs do help. In the end, Eclipse is a community of mutual self > interests ;) Chris, AFAIK, most (critical majority) Eclipse commits are by people from companies which invest in Eclipse. These people are getting paid to work on Eclipse by their companies (and I'm sure they do well above and beyond). Each company invests money because it has an agenda and I wouldn't expect it to be different. Apple, decided that it wants more apps in the app store. So, they made it super easy to write and deploy applications. Before they issued the SDK and opened the App store itself there was just a trickle. Now, there's a flood. If one of the companies involved in Eclipse wants to open the flood gates of (professionaly developed and maintained) plugins there are a number of steps which should be taken. One of those steps is to provide a super easy way of deploying and distribute plugins to customers. I don't expect this to happen overnight, but we should be moving in that direction. And that's mine. (In reply to comment #14) > If one of the companies involved in Eclipse wants to open the flood gates of > (professionaly developed and maintained) plugins there are a number of steps > which should be taken. One of those steps is to provide a super easy way of > deploying and distribute plugins to customers. I don't expect this to happen > overnight, but we should be moving in that direction. > Sounds like what we set forth doing with the spaces project. Perhaps it's time to blow some new life into that? http://www.eclipse.org/spaces/ (disclaimer: rehash here) This problem should be solved by a single solution, which also addresses: - better O/S (a.k.a. shell) integration: the ability to associate file types with actions in the Eclipse IDE. By initiating the O/S's stereotypes for 'edit' (as e.g. on the Windows platform, say by clicking on it in Exploder), that file (through file extension association) is opened either in an IEditor without a backing workspace resource, a link to that resource in a user-selected project, or a copy of that file to a user-selected project. - better web integration: the ability to rely on 'Helper Applications' a concept known in Mozilla (@see http://www-archive.mozilla.org/docs/end-user/helper-applications.html), which intercepts linking to resources of given MIME types or file extensions. Typical for helper applications is the 'use default' option to delegate handling to the underlying O/S. My focus is investigating how this can all be tied to https://bugs.eclipse.org/bugs/show_bug.cgi?id=178927 (pass arguments to the launcher). And in addition, it needs to work for all supported platforms in a uniform way. We're making progress with the ECF IPC project to provide the solution at the lowest-level (native) part. ECF IPC aims to cover all supported platforms, as well - so that should allow this library to come up with either suggestions to update the native launcher, or have the launcher use ECF IPC directly. (There is also the case of having multiple Eclipse IDE's open at the same time, something observed in the wild, and admittedly, which I also do sometimes. A fun requirement, indeed. And how about an Eclipse app running as a child from a run target. People will be really disappointed if they can't try their stuff that way.) (In reply to comment #16) > (disclaimer: rehash here) > > This problem should be solved by a single solution, which also addresses: > > - better O/S (a.k.a. shell) integration... Yes, exactly. But, if we are going to reduce/extend this proposal to this, I will open a different issue: enable simple programmable plugin installation from within the platform. The way the P2 director is architected really doesn't answer that very well. > - better web integration... It would be very nice to have. It seems like a separate issue to me. > My focus is investigating how this can all be tied to > https://bugs.eclipse.org/bugs/show_bug.cgi?id=178927 (pass arguments to the > launcher). Yes, but don't forget that, in many cases, the platform is already launched. Thus, you need to inform the running platform. > (There is also the case of having multiple Eclipse IDE's open at the same time, > something observed in the wild, and admittedly, which I also do sometimes. A > fun requirement, indeed. And how about an Eclipse app running as a child from a > run target. People will be really disappointed if they can't try their stuff > that way.) You may safely remove the parenthesis :-) When I code I usually have more than one Eclipse running (this works really well on OS X, BTW, less on Windows, maybe that's why it's less common). Besides, RCP based applications also count. For example, many times I use XMind and Eclipse IDE at the same time. I wouldn't say this is an obscure case. Fun? indeed! #funtheory This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. I'll assume that everything is baked in stone now... |