Re: [equinox-dev] [prov] p2 / browser integration
At the Equinox summit there was some discussion around how to discover and communicate with existing instances of Eclipse when either someone double clicks on a shortcut or clicks on a link in a browser. There was some discussion around a Google SOC project as well as the use of commands and console integration. It would be good for someone to prototype an actual working setup here so that we can kick around various options and approaches. For the first cut there does not seem to be a need for doing native stuff (seems like an optimization). I noticed the other day that ECF has some discovery code that might make sense here as well? anyone willing to look at this and do a prototype? Jeff Brett Hackleman [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 12:22 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] [prov] p2 / browser integration Forgot to mention some simple approaches we could also consider for the UpdateManager: 1. The UI could detect a standard http:// site or feature URL on the clipboard, or allow the user to paste it easily into the main UM dialog without forcing them to Add Remote Site... or even better, 2. The UI could allow links to be drag and dropped from the browser, into the main Eclipse workbench or the UM, kicking off the install. Providing sample Eclipse package, drag to install graphics for use on the web could make this more intuitive. (Susan, I haven't looked at the new UI yet, so please forgive me if some of this is no longer applicable) -Brett Jeff McAffer wrote: I agree that forcing people to browse via Elcipse is unfortunate. It will address some of the usecases but not all. As for XPI, I'm not sure we need to define some new packaging. We have the p2 stuff so all we really need to do is give p2 enough data that is knows what it is to install. In theory this could be as simple as the ID and version of an IU. p2 does the rest based on the current settings etc of the agent. XPI seemed like overkill in our situation. Jeff *Andrew Overholt [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 10/23/2007 11:10 AM Please respond to Andrew Overholt [EMAIL PROTECTED]; Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] [prov] p2 / browser integration Hi, * Chris Aniszczyk [EMAIL PROTECTED] [2007-10-23 10:36]: If you use the Eclipse browser to browse download sites or something like EPIC While I completely agree that we need some easy method of installing and that it would be ideal to do so from a web browser, wouldn't this solution require one to basically do all of their browsing from within Eclipse? As hard as it will be, I think native handlers are the way to go here. I'd love to be proven wrong, though, because I know how difficult it will be -- especially with multiple running Eclipse instances. Andrew ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Brett R. Hackleman Vice-President Band XI International, LLC 11362 E. Whitethorn Dr. Scottsdale, AZ 85262 USA Mobile: (602) 326-7374 GSM email: [EMAIL PROTECTED] web:http://www.bandxi.com ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Proposal for an OSGi spec work area in the equinox incubator
The OSGi Next work area http://www.eclipse.org/equinox/incubator/osgi-next/ has been created. To begin the work on the Framework I have populated the current I-Build (v20071022) of org.eclipse.osgi into the osgi-next work area in CVS (equinox-incubator/osgi-next/org.eclipse.osgi) Tom From: Thomas Watson/Austin/[EMAIL PROTECTED] To: equinox-dev@eclipse.org Date: 10/16/2007 04:23 PM Subject:[equinox-dev] Proposal for an OSGi spec work area in the equinox incubator I would like to start a new work area in the Equinox incubator to support prototyping and investigating future OSGi specifications. The goal behind this work area is to develop an implementation of the specification as the specification is being developed. This work area will allow others to more easily join in on the investigations for future OSGi implementations. To begin with this work area would be used to implement the next release of the OSGi Framework, but other future OSGi specifications could also be contributed. This will also allow Equinox to provide reference implementations to OSGi without effecting the current Eclipse release. We would only graduate the code out of the incubator once the OSGi specification has gone public/final and we can align it with a major Eclipse release. I would like to take a vote to approve the OSGi spec work area in the equinox incubator. Tom - Forwarded by Thomas Watson/Austin/IBM on 10/16/2007 03:45 PM - From: Thomas Watson/Austin/IBM To: equinox-dev@eclipse.org Date: 10/12/2007 01:34 PM Subject:OSGi R4.2 Stream The OSGi Alliance is busy working on the next release of the specification. The release of the next OSGi specification will be long after the Eclipse 3.4 (Ganymede) release. To achieve a stable Ganymede release we will not release new OSGi R4.2 API or implement new R4.2 functions in the Ganymede stream (HEAD). We need a place where we can continue to implement and prototype the next OSGi specification release as it is being developed. I see two options. 1) Create an area in the Equinox incubator to develop the OSGi R4.2 implementation 2) Create a branch off of the current Ganymede stream (HEAD) for OSGi R4.2 implementation I prefer using a branch instead of a separate repository project in the incubator because it will make life easier when developing streams in parallel, which we will likely need to do until the Ganymede release in June 2008. I plan to create a branch based of next weeks I-Build for the OSGi R4.2 work. Please let me know if you have any issues with this. Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: ecblank.gifinline: 08081209.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] generator changes
The use case I added support for was generating IUs for all platform launchers when generating against an Eclipse install that contains the delta pack. It does consult IGeneratorInfo to get the location of the org.eclipse.equinox.executable feature where the launchers live, but from that point it makes assumptions about the shape of the executable feature. It does this to figure out the os/ws/arch values and to figure out the native touchpoint instructions (zip and chmod) so that the resulting install will have the right shape. Overall, it feels quite brittle to be reverse-engineering the launcher configuration units based on the delta pack structure produced by PDE build. There are subtle details such as which files need the execute bit set, etc. I was thinking this will be a good candidate for hand-crafting metadata once we have a stable metadata file format. The launcher metadata could be authored at develop time, and checked into CVS alongside the actual launcher files. Jeff McAffer/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 02:44 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] [prov] generator changes I noticed a few changes around the generator that seem to embed knowledge of the launcher etc in the generator itself. would it be reasonable to separate these out and put that stuff into the GeneratorInfo? The idea of the design is that the generator itself is reasonably generic and the infos fill in the details for particular scenarios. Currently we only have on info class but thta is more of a current state than anything. Thoughts? Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [prov] generator changes
Ok. approach makes sense. This may also be a good candidate for advice to the generator. The info is in effect advice but we need ways of letting users give such input more easily. That is essentially why I was pushing on moving this stuff out of the generator. Things like the names and locations of the executables should come from outside. Jeff John Arthorne/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 07:53 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] [prov] generator changes The use case I added support for was generating IUs for all platform launchers when generating against an Eclipse install that contains the delta pack. It does consult IGeneratorInfo to get the location of the org.eclipse.equinox.executable feature where the launchers live, but from that point it makes assumptions about the shape of the executable feature. It does this to figure out the os/ws/arch values and to figure out the native touchpoint instructions (zip and chmod) so that the resulting install will have the right shape. Overall, it feels quite brittle to be reverse-engineering the launcher configuration units based on the delta pack structure produced by PDE build. There are subtle details such as which files need the execute bit set, etc. I was thinking this will be a good candidate for hand-crafting metadata once we have a stable metadata file format. The launcher metadata could be authored at develop time, and checked into CVS alongside the actual launcher files. Jeff McAffer/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/23/2007 02:44 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To equinox-dev@eclipse.org cc Subject [equinox-dev] [prov] generator changes I noticed a few changes around the generator that seem to embed knowledge of the launcher etc in the generator itself. would it be reasonable to separate these out and put that stuff into the GeneratorInfo? The idea of the design is that the generator itself is reasonably generic and the infos fill in the details for particular scenarios. Currently we only have on info class but thta is more of a current state than anything. Thoughts? Jeff ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
RE: [equinox-dev] [prov] p2 / browser integration
Could you guys check out what done of our student did this summer to address that very issue? http://wiki.eclipse.org/Google_Summer_of_Code_2007 http://wiki.eclipse.org/Eclipse_Web_Interface -- Cheers Philippe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Hackleman Sent: Tuesday, October 23, 2007 7:11 AM To: Equinox development mailing list Subject: [equinox-dev] [prov] p2 / browser integration I'd like to submit this as a feature request, but wanted to solicit feedback here first. Apologies for the long post. === (BTW, in this feature request I'm a bit loose with the terminology re: site.xml, features, etc... I realize this has all changed in p2, but I'm sticking with the old terms since they make more sense in this discussion). One of the major pain points with the old UpdateManager is that users must create remote sites by typing the update site URL manually into the UM dialog. 9 times out of 10, the URL is copied pasted from the browser, and the user is most likely going to install the only feature available in the site.xml (as advertised on the web page he copied the link from). I see two possible approaches for providing better integration between the browser and Eclipse. Both assume we have a native application capable of handing the site URL and other information into p2. 1. Register a file handler for the meta-data file extension with the OS. The browser would then prompt the user to download or open the file using the associated file handler. This would require a custom and unique file extension (*.ep2) to avoid conflict with other applications. 2. Register a URI handler (such as eclipse://) with the OS. The feature publisher would build a link to his update site URL (and possibly the name of the feature to be auto-installed). When clicked, the browser will pass the entire link to our native application. Once the native application has been launched with this site information (whether by URI or file extension), it would need a way to pass the information to the p2 install agent. Of course we may have 0-N eclipse instances running (with 0-N p2 agents as well?) so we would need to handle each of these scenarios. At first glance the safest and most flexible approach might be to store the site/feature information to a temporary file where a p2 directory watcher could find it. I realize this is a fairly complex scenario, but it would enchance the user experience considerably. Some best practice docs and a few sample Eclipse feature download button images (seach for Firefox extensions and notice the Firefoxy install buttons) would go a long way, and possibly encourage early-adoption of p2 by feature providers. = Thoughts? -Brett ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
