Community
Participate
Working Groups
Currently the extension location repo implementation doesn't recognize zip files. To deal with this, the UI unzips zip files and then tries again with the repo manager. There are issues with this: - not clear unzipping in the install location is allowed - different brand of "magic" than what happens in core - Pascal doesn't like it ;-) This is the only place in the UI (so far) where decisions are made about where to put things, which seems bogus. Should the extension location repo accept a zip file and do its own unpacking?
It turns out the UI "magic" of unzipping locations was broken while fixing bug #225062. We need to figure out what we want to do for zip files that are not already p2 repositories. What we used to do was validate the repo URL synchronously, and if no one recognized it, as a last-ditched effort the UI would say, "hey, it's a zip file, I'll unzip it and then try again." This would in turn allow the extension location repo to handle the URL. We no longer can do this validation synchronously, so we must go ahead and add the URL. Later on, when the repo is loaded, all of the repo factories reject the URL and the load fails. Perhaps at this point the UI could kick in and try to do the unzip, but I think this is the wrong approach. If we are to support zipped up files, it would be better to handle inside the extension location factory. We would need to handle a URL like this: jar:file:C:\_downloads\tests\emf-runtime-2.4.0M6.zip!/
I think at this point we should just fail when the user tries to add a zip file as a site that is not a p2 repo zip. The workaround is for users to unzip the file and add the folder. Marking this RC1 so I can remove the UI code that was attempting to handle this case. Once I've done that, I'll remove the milestone and keep this bug around as a future enhancement request.
code is being removed in bug #222639, so removing milestone on this bug.
Simon, is this bug still relevant? (Or do we now handle zipped eclipse folders now as extension location repos...)
Marking WONTFIX We can re-open later if it's really interesting however for now I'm not intending to add this. The extension repo is fairly dependent on file operation so in order to do this we would have to fetch and unzip in a cache somewhere and then run the directory watcher to generate artifact descriptors and metadata. I think users are better off using a native p2 repo if they want to do zipping or if they're determined can do the unzipping themselves.
