Community
Participate
Working Groups
In bug 345622, I'm trying to surface some interesting commands in the navigator that let the user quickly create content. Of course one of the most common ways to create content is to clone a git repository. I don't want to make the navigator dependent upon (and load) gitCommands. So the temporary solution is that the "Create a git clone" link in the navigator simply links to the repo page and opens the clone repository slideout. This is better than before (following some ugly links in the getting started page) but is still not nearly as nice as simply having the folder appear in your navigator after you've typed a URL in the navigator. So the question is...what would it take to get "clone repository" working in a plugin command? - it needs to collect a URL parameter. That would involve exposing command parameters in the extension points, which seems perfectly reasonable. But after that.... - how does the implementation get all the services that its currently using in the command implementation. - how does it handle authentication etc... This seems like a really good candidate scenario for "plugins that need to authenticate", "plugins that need to talk to shell services" etc...
Ken/Simon - if we think it's important to have a "quick and easy clone from navigator" story for 0.5, and we can't make it work from a plugin, another approach would be to do a more trivial refactoring of gitCommands so that the minimal code needed to perform a clone was loaded in the navigator up front rather than loading all of gitCommands.
I think that splitting gitCommands into smaller chunks is a good idea anyway. For instance I do not need to load whole gitCommands on the status page, there are just some specific commands I need etc. For git clone as a plug-in command we also need to make sure that we track and show the progress of cloning operation.
(In reply to comment #1) Simon has been working with what it would take to minimally support Orion offline. One use case is the HTML5 File system which would not support (at the moment) Git. So if we had the navigator in this scenario, would it pull in unwanted Git code and commands that were not usable? Or could they be toggled hidden or unavailable in this case? Seems at the moment our Git and Orion File System support are tied together.
(In reply to comment #3) File system that is tied with Git support returns Git section in file API responses. For instance GET on a file would return file details + Git section with locations of a repo, index etc. We show Git commands in navigator if the Git section is present. I guess that HTML5 filesystem will not return the Git section so Git commands in the navigator will not be visible for files from this filesystem.
(In reply to comment #3) > (In reply to comment #1) > > Simon has been working with what it would take to minimally support Orion > offline. One use case is the HTML5 File system which would not support (at the > moment) Git. So if we had the navigator in this scenario, would it pull in > unwanted Git code and commands that were not usable? Or could they be toggled > hidden or unavailable in this case? Seems at the moment our Git and Orion File > System support are tied together. I'm only talking about "clone git repository" in this bug. Not too worried about the other commands. I want the ability to specify a URL in the nav and clone a repo, have it appear. As I understand it, it requires some file system, but in "theory" you could clone a git repo into your HTML5 local file system, because git is talking to fileClient and doesn't care what underlying implementation is there. But I suspect we have other ties to the Orion server...Szymon, does git use fileClient and have file system neutrality or does it depend on the Orion server being there in particular. As I see it there are two ways to support clone from nav 1) get git clone as a plugin command. Then no code is loaded til you need it. Just not sure it's realistic since you need some shell services/workspace writing from a plugin. 2) put the clone command in its own minimal js file. We pull that file into the nav (not ideal) but the win is that the user clicks one button in the navigator rather than "welcome to Orion, click this button to clone a repo, now you have to go to another page, hit enter, and then go back to the navigator." And then separately we have to decide..."do you need orion file system to use git or is html5 enough?"
(In reply to comment #2) > I think that splitting gitCommands into smaller chunks is a good idea anyway. > For instance I do not need to load whole gitCommands on the status page, there > are just some specific commands I need etc. Can we do this for 0.5? Or minimally can we get clone separated from the rest so the user can clone from the nav?
*** Bug 382193 has been marked as a duplicate of this bug. ***
bug378755 commit e85cd6902e0df4af205e82e816d61b14d056a12b. Susan can you review?
+ small change in commit 3d20690eeb95f3326343d88d3e98b6431bb36866 on the same branch bug378755.
Talked to Simon and Ken about this. Two major concerns: 1) there is a bug in that favorites pane is being erased when the clone completes. Need to investigate. 2) Simon is adamant that we should not be bringing in a hard module dependency on git in the nav page. But that is more work (reread comment 0). I promised to investigate some hybrid approach where the command is contributed by a plugin (but maybe the implementation is brought in from the plugin rather than the nav page). I'm not sure there is a feasible middle ground here, but I just want to try a few evil hacks.
I really, really wanted this to go in. I immediately lost confidence when Ken found the "favorites disappears" bug. Especially because I did not notice this bug. So I wanted to investigate it, because it is such a strange symptom. And worse, it's not just clone that causes favorites to disappear, even deleting a file causes it to disappear. We aren't rerendering favorites or anything purposefully. I put breakpoints in all the places that decide to redraw favorites. The dom nodes are simply getting resized to be invisible (the section content is resized to 4px high). I put a breakpoint into the clone command to see where/why this happens and I can't get there. Instead I get Aww snap and not only in my page, but in every self hosted and orion.eclipse.org page. So something really strange is going on. I cleared local storage, cleared my browser cache, reloaded every plugin, making sure that it's not something in my site or browser. At this point, given concern #2 I think we are going to have to defer this bug. Regarding concern #2...I tried to think of any way possible to get that command registered only when the git plugin loads. But of course any hack that says a plugin can somehow secretly run in-page code is an even worse architectural problem than saying the navigator pulls in git code. So...we are going to have to wait on this one.
Created attachment 217310 [details] screenshot of crash while debugging clone command
Something really weird is going on. Now I'm starting to think that Szymon's changes had nothing at all to do with this bug. Because it just happened on orion.eclipse.org. When Ken told me of the problem, I tried orion.eclipse.org and it did not have the problem. Maybe it's something else recent that causes the problem. (Checking whether we just promoted a new build). The build id footer is also gone from orion.eclipse.org so I can' t be sure.... Will follow up...
We think the "favorites disappearing" bug has been there already (not sure how long). I know I checked this on orion.eclipse.org when we were reviewing the code, but perhaps I wasn't in the root, and the root has the problem. Opened bug 382538. Missing build id in navigator footer is a different bug. Opened bug 382539. Sorry to blame your fix on the favorites disappearing. I'm not sure why I thought the bug wasn't there in orion.eclipse.org, I thought I had tried this immediately when we found it on the self hosted site and did not see it happen.
Susan, are we releasing the fix or we are working on another approach?
(In reply to comment #15) > Susan, are we releasing the fix or we are working on another approach? I believe Simon wanted us to "do the right thing". Which is bug 378749. But I think we should keep this bug open until we know for sure. In the meantime, if you wanted to break up the commands anyway (comment 2) that can only help later.
This bug is no longer valid. I cloned it in bug 397768 to reduce some of the clutter. We are going to have a projects page that creates certain kinds of projects. This is where we would either: (short term) - expose a link to the clone page (longer term) - have a "create git project" that did the clone.
