Community
Participate
Working Groups
This Bugzilla is for reporting problems or suggesting enhancements related to the Oomph wiki tutorial for Eclipse Platform SDK Provisioning: https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
Ed, I just clicked through your wiki. I got totally lost at the "bundle pool" topic. I dragged the configuration link and was then in the advanced mode when reading the "bundle pool" stuff. I found the bundle pool stuff after I pressed "back" several times. So I think the order is wrong on the wiki page.
does the installer always clone all the git repos? Can I re-use git clones I already have on my disk?
Good point. It would not be nice to have your disk overfilling before realizing that might happen. It really should be moved to the section about launching. I've made that change. Thanks for the feedback!
There are different rules you can choose for where the clones are located. The default is it create it in a folder parallel to the installation. Same goes for the location of the workspace that's used. But you can put them in a common root folder as well, or in the workspace. But note that I'm not a big fan of shared clones between workspaces. You cannot do that properly if both workspaces are actually running. Each will workspace try to build into the same folders, and of course you can't check out different branches in each workspace. So yes, it's more time and more space to have a separate clone, but it also keeps you from making a big shared mess.
The example described on https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning did import the org.eclipse.swt.examples.ole.win32 plugin into the workspace. As I am on a mac this does provide comiple errors. I think this plugin should not be put into the workspace on macOS.
When provisioning as described on https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning The workspace and the "Platform UI Tests" project set does not contain the new plugin org.eclipse.tests.urischeme. The new plugins org.eclipse.ui.examples.uriSchemeHandler and org.eclipse.urischeme however *are* contained in the respecting working set.
(In reply to Matthias Becker from comment #6) > When provisioning as described on > https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning > > The workspace and the "Platform UI Tests" project set does not contain the > new plugin org.eclipse.tests.urischeme. > This was your own fault. :-P https://bugs.eclipse.org/bugs/show_bug.cgi?id=530834#c37 If you commit the file, do a pull, and then use Help -> Perform Setup Tasks... again (just the Modular Targlet task needs to be performed), that project should be properly imported. > The new plugins org.eclipse.ui.examples.uriSchemeHandler and > org.eclipse.urischeme however *are* contained in the respecting working set. Thanks so much for actually testing the tutorial. I really appreciate that!
(In reply to Matthias Becker from comment #5) > The example described on > https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning > > did import the org.eclipse.swt.examples.ole.win32 plugin into the workspace. > As I am on a mac this does provide comiple errors. I think this plugin > should not be put into the workspace on macOS. I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=536674 and committed a fix to Gerrit. I'll submit it shortly. Thanks again! Now that I pulled all repos I see some errors. Some things about bundle versions not being incremented and some unused exception variable problems. I'll investigate those to see why they show up now.
The errors in org.eclipse.compare.core are caused by this commit adding project-specific preference that diagnoses the unused exceptions as an error: https://git.eclipse.org/r/#/c/125362/ I was under the impression that commits should have an associated Bugzilla. :-(
https://wiki.eclipse.org/Platform/How_to_Contribute#.5B1.5D_Get_an_Eclipse_SDK recommends to use a recent I-Build for the Eclipse SDK for contributions. However, as far as I know, it is not possible to select I-Builds as product versions in Oomph.
It is possible. It's called the Eclipse SDK. In advanced mode you'll find it in the Eclipse.org Applications Product Catalog. It's a fairly recent addition to the catalog. I should update the Configuration to use it now...
(In reply to Ed Merks from comment #11) > It is possible. It's called the Eclipse SDK. In advanced mode you'll find > it in the Eclipse.org Applications Product Catalog. It's a fairly recent > addition to the catalog. I should update the Configuration to use it now... 1. From a quick look at the configuration, I don't think that this will use the current 4.13 I-Builds already. 2019-09 development starts before 2019-06 is released, so currently there is a newer release then 'Latest'. 2. The Eclipse SDK product fails for me now: ERROR: org.eclipse.equinox.p2.director code=10053 Cannot complete the install because one or more required items could not be found. at org.eclipse.oomph.util.OomphPlugin.coreException(OomphPlugin.java:280) at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.resolve(ProfileTransactionImpl.java:425) at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:337) at org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:751) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3824) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3752) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3733) at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3626) at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:575) at org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:701) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) ERROR: org.eclipse.equinox.p2.director code=0 Software being installed: artificial_root 1.0.0.v1560611262330 ERROR: org.eclipse.equinox.p2.director code=0 Missing requirement: Oomph Setup Git 1.7.0.v20170104-1401 (org.eclipse.oomph.setup.git 1.7.0.v20170104-1401) requires 'osgi.bundle; org.eclipse.egit.core [3.0.0,5.0.0)' but it could not be found ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency: ERROR: org.eclipse.equinox.p2.director code=0 From: artificial_root 1.0.0.v1560611262330 ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.oomph.setup.git.feature.group 0.0.0 ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency: ERROR: org.eclipse.equinox.p2.director code=0 From: Oomph Setup Git 1.7.0.v20170104-1401 (org.eclipse.oomph.setup.git.feature.group 1.7.0.v20170104-1401) ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; org.eclipse.oomph.setup.git [1.7.0.v20170104-1401,1.7.0.v20170104-1401]
Yes, the timing of the release train releases versus the timing of the Eclipse SDK releases (which is technically not yet released) in combination with the timing of the development team's move of master to a future release is kind of unfortunate and currently not taken into account by the product catalog generator. I'll need to address that... But the stack trace is a little suspicious given I've already tested this. I.e., this looks very old. org.eclipse.oomph.setup.git 1.7.0.v20170104-1401 That bundle is currently at version 1.13 and specifies: org.eclipse.egit.core;bundle-version="[2.0.0,6.0.0)" When I try in advanced mode the Eclipse SDK 4.12 version all by itself it installs fine. And when I try it in combination with the Platform UI project it all installs fine. The log has this information: Executing bootstrap tasks Java(TM) SE Runtime Environment 1.8.0_121-b13 Product org.eclipse.applications.eclipse.platform.sdk.latest Workspace C:\user-home\ui-master\ws Project org.eclipse.platform.ui.master Bundle org.eclipse.oomph.setup 1.13.0.v20190530-1228, build=4035, branch=ed8d2fdcc99c1d3461399fc1bee02645433fa697 Bundle org.eclipse.oomph.setup.core 1.13.0.v20190531-1228, build=4035, branch=ed8d2fdcc99c1d3461399fc1bee02645433fa697 Bundle org.eclipse.oomph.setup.installer 1.13.0.v20190530-1228, build=4035, branch=ed8d2fdcc99c1d3461399fc1bee02645433fa697 Bundle org.eclipse.oomph.setup.p2 1.11.0.v20190530-1228, build=4035, branch=ed8d2fdcc99c1d3461399fc1bee02645433fa697 Performing Workspace C:\user-home\ui-master\ws Performing P2 Director (Eclipse SDK (4.12 - 2019-06) + Platform + VI) Offline = false Mirrors = true Resolving 13 requirements from 5 repositories to C:\user-home\ui-master\eclipse Requirement org.eclipse.platform.feature.group Requirement org.eclipse.jdt.feature.group Requirement org.eclipse.pde.feature.group Requirement org.eclipse.pde.api.tools.ee.feature.feature.group Requirement org.eclipse.sdk.ide [4.12.0,5.0.0) Requirement org.eclipse.oomph.setup.feature.group Requirement org.eclipse.oomph.targlets.feature.group Requirement org.eclipse.oomph.setup.targlets.feature.group Requirement org.eclipse.oomph.setup.pde.feature.group Requirement org.eclipse.oomph.setup.jdt.feature.group Requirement org.eclipse.oomph.setup.git.feature.group Requirement org.eclipse.egit.feature.group Requirement org.eclipse.oomph.setup.workingsets.feature.group Repository http://download.eclipse.org/eclipse/updates/4.12-I-builds Repository http://download.eclipse.org/oomph/updates/latest Repository http://download.eclipse.org/modeling/emf/emf/builds/release/2.17 Repository http://download.eclipse.org/egit/updates Adding repository http://download.eclipse.org/egit/updates Adding repository http://download.eclipse.org/eclipse/updates/4.12-I-builds Adding repository http://download.eclipse.org/oomph/updates/latest Adding repository http://download.eclipse.org/modeling/emf/emf/builds/release/2.17 Calculating requirements and dependencies. So Oomph's update site is available, pointing at a very recent version, and the EGit update site is available, also point at a very recent version. So how is possible that with what you tried, it tried to install an very old version of Oomph? It would be good to see the first part of the log where I can see which version of Oomph is used by the installer, which requirements are specified, and which update sites are available/used. This way I can better understand exactly what you did.
Created attachment 278951 [details] Error logs; eclipse-inst.ini, failure log, succes log My Oomph is updated to the latest (released) version 1.13.0 Build 4030, the install is around for about 2 years. When I select 'Eclipse Platform' as product the installation works fine. When I select 'Eclipse SDK' I get the error. In the attached file: - eclipse-inst.ini - log of failure with Eclipse SDK - log of success with Eclipse Platform
(In reply to Rolf Theunissen from comment #14) > Created attachment 278951 [details] > Error logs; eclipse-inst.ini, failure log, succes log > > My Oomph is updated to the latest (released) version 1.13.0 Build 4030, the > install is around for about 2 years. > > When I select 'Eclipse Platform' as product the installation works fine. > When I select 'Eclipse SDK' I get the error. > > In the attached file: > - eclipse-inst.ini > - log of failure with Eclipse SDK > - log of success with Eclipse Platform I notice the following difference in my logging vs. yours, mine: Repository http://download.eclipse.org/oomph/updates/milestone/latest yours: Repository http://download.eclipse.org/oomph/updates/latest
That explains it! Of course I assume that http://download.eclipse.org/oomph/updates/milestone/latest points at the latest milestone, but because of a bug the the composition process, it actually points at something old! I'm so glad you found this!!! Note the difference is that I was using a nightly-build installer that updates from the nightly build repository whereas you are using the milestone (release) installer and it installs from the milestone repository...
The problem with the repository composing the wrong version of Oomph is fixed now. I'll have to keep an eye on it the next time I promote a milestone build.
I can confirm that it works perfectly now. B.T.W. I have a workaround for the 4.13 I-Build not available yet, I added the following redirect rule to my eclipse.ini. With this rule I am running the latest 4.13 I-Build. -Doomph.redirection.ibuilds.workaround=http://download.eclipse.org/eclipse/updates/4.12-I-builds->http://download.eclipse.org/eclipse/updates/4.13-I-builds
Rolf, I very much appreciate your feedback! I've changed the Configuration to use the latest Platform SDK produce version: index:/org.eclipse.setup#//@productCatalogs[name='org.eclipse.applications']/@products[name='eclipse.platform.sdk']/@versions[name='latest']" I just tested that it properly works for the full SDK, installing Eclipse 4.13's latest I build. That all continues to work well for me. I think the biggest glitch going forward is the time gap between when the platform team actually starts 4.14 development versus when the 2019-09 train and the platform 4.13 release is actually public. So when we get to that transition in the next cycle, I will revisit how the product catalog generator works such that I can generate a product version for 4.14 at an earlier time. Of course I'll also look closely at https://bugs.eclipse.org/bugs/show_bug.cgi?id=548539 to figure out which tools should be installed that are not currently installed. Thanks again for your feedback.
Hi Ed, I tried the configuration, but the first step from https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning fails for me: ---- Drag and drop the Platform SDK Configuration link on the title area of the installer. ---- I'm not sure what the title area is but I tried several places, see video which I uploaded here: https://vimeo.com/357416839
(In reply to Lars Vogel from comment #20) > Hi Ed, > > I tried the configuration, but the first step from > https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning fails for me: > > ---- > Drag and drop the Platform SDK Configuration link on the title area of the > installer. > > ---- > > I'm not sure what the title area is but I tried several places, see video > which I uploaded here: https://vimeo.com/357416839 My answer from yesterday seems to have gotten lost. Drag and drop does not always work so well on Linux; too many variants and it behaves quite differently from Windows, i.e., not providing the drag source until you actually drop. I'll have to test again on my virtual box, but that's a long and painful process. Not only that a breakpoint during drag and drop can lock the whole desktop making it even more painful to debug. In any case, that's why an alternative approach is implemented and documented: As an alternative to drag-and-drop, you can copy the Platform SDK Configuration link, and apply it to the installer. In simple mode, this is done via the menu action; this action will appear in the menu only if the clipboard contains a valid configuration Does that work for you?
(In reply to Ed Merks from comment #21) > Does that work for you? Yes, thanks. I think I tried this also yesterday and the menu was flickering a lot so I stopped. Today it worked without flickering.
Created attachment 279758 [details] Invisible toolitems During the setup phase I "feel" two invisible toolitems, if I hover above them, I see them.
(In reply to Lars Vogel from comment #23) > Created attachment 279758 [details] > Invisible toolitems > > During the setup phase I "feel" two invisible toolitems, if I hover above > them, I see them. I think it's just one, but yes, more Linux only things that vary subtly depending GTK versions and will work well for a while, and then something changes in GTK or SWT, and it doesn't work well yet again. Something else to look into when I can find time to fire up a virtual box; my Maco one tends to stop working from atrophy and is much harder to set up than for Linux, which by now is probably a fossil version... Of course it's all open source, but whoever contributes when it's so much easier just to report problems and hope for the best? :-P
(In reply to Ed Merks from comment #24) > Of course it's all open source, but whoever contributes when it's so much > easier just to report problems and hope for the best? :-P As I'm doing all my Open Source activities unpaid, I have limits, like you also have. And since a few months I'm already way to much above my max limit. See https://projects.eclipse.org/projects/eclipse/who and let me know if you think I "just report problems".
(In reply to Lars Vogel from comment #25) > (In reply to Ed Merks from comment #24) > > Of course it's all open source, but whoever contributes when it's so much > > easier just to report problems and hope for the best? :-P > > As I'm doing all my Open Source activities unpaid, I have limits, like you > also have. > And since a few months I'm already way to much above my max limit. See > https://projects.eclipse.org/projects/eclipse/who and let me know if you > think I "just report problems". Sorry, I can see that you would interpret my comment as something specifically aimed at you. That was not what I had in mind at all! Sorry, sorry! There are just so many issues, it's hard to even keep track: https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Tools&component=Docs&component=Dynamic%20Working%20Sets&component=P2%20Management&component=Preferences%20Management&component=Project%20Configuration&component=Release%20Engineering&component=Setup&component=Targlets&component=Tools&component=Utilities&component=Version%20Management&list_id=18905488&order=bug_id%20DESC&product=Oomph&query_format=advanced And then in a thread like this, it seems it's offensive to even suggest someone could contribute: https://bugs.eclipse.org/bugs/show_bug.cgi?id=543239 So that's the kind of thing I had in mind when I commented thoughtlessly.
(In reply to Ed Merks from comment #26) > Sorry, I can see that you would interpret my comment as something > specifically aimed at you. That was not what I had in mind at all! Sorry, > sorry! No worries, my friend. Thanks for the clarification.
If I run the Platform configuration setup, all the clone Git repos are not configured with my user. So instead of using: git clone ssh://lvogel@git.eclipse.org:29418/platform/eclipse.platform.ui or git clone https://lvogel@git.eclipse.org/r/a/platform/eclipse.platform.ui it seems to have used: git clone https://git.eclipse.org/r/platform/eclipse.platform.ui I'm still not very familiar with the Platform Oomph setup, did I miss a step? Changing all the repositories push URLs manually seems to be against the concept of Oomph for automatic configuration of all tasks.
(In reply to Lars Vogel from comment #28) > If I run the Platform configuration setup, all the clone Git repos are not > configured with my user. > > So instead of using: > git clone ssh://lvogel@git.eclipse.org:29418/platform/eclipse.platform.ui > or > git clone https://lvogel@git.eclipse.org/r/a/platform/eclipse.platform.ui > > it seems to have used: > git clone https://git.eclipse.org/r/platform/eclipse.platform.ui > > I'm still not very familiar with the Platform Oomph setup, did I miss a step? > > Changing all the repositories push URLs manually seems to be against the > concept of Oomph for automatic configuration of all tasks. It appears you did not read the instructions in the wiki: The long list of variables is mostly the result of the different choices available for the URI used to clone each Git repository. Currently there are six choices, but that may soon be reduced to three if the Eclipse Foundation eliminates the non-Gerrit servers. All the clone URIs for the Platform SDK Configuration's repositories default to anonymous, read-only Gerrit access. If you are a committer, or a contributor with a Gerrit account, you will want to change each of these URIs to a form that allows read-write access. If you do not have a Gerrit account, you should get one immediately! When you select the SSH (read-write, Gerrit) choice, a new variable prompt, Eclipse Git/Gerrit user ID, will appear at the very bottom. Here you should enter your Eclipse account ID, e.g., for me, emerks. Note that if you find it very painful to change each of the many URIs in the dialog, you'll only ever have to do this once, because the installer will remember this choice and will no longer display the variable, unless you check Show all variables, in which case you can change the choice you made previously.
(In reply to Ed Merks from comment #29) > (In reply to Lars Vogel from comment #28) > > If I run the Platform configuration setup, all the clone Git repos are not > > configured with my user. > > > > So instead of using: > > git clone ssh://lvogel@git.eclipse.org:29418/platform/eclipse.platform.ui > > or > > git clone https://lvogel@git.eclipse.org/r/a/platform/eclipse.platform.ui > > > > it seems to have used: > > git clone https://git.eclipse.org/r/platform/eclipse.platform.ui > > > > I'm still not very familiar with the Platform Oomph setup, did I miss a step? > > > > Changing all the repositories push URLs manually seems to be against the > > concept of Oomph for automatic configuration of all tasks. > > > It appears you did not read the instructions in the wiki: I once joined a presentation from you in which you said, Oomph makes reading the instructions unnecessary. > The long list of variables is mostly the result of the different choices > available for the URI used to clone each Git repository. Currently there are > six choices, but that may soon be reduced to three if the Eclipse Foundation > eliminates the non-Gerrit servers. All the clone URIs for the Platform SDK > Configuration's repositories default to anonymous, read-only Gerrit access. > If you are a committer, or a contributor with a Gerrit account, you will > want to change each of these URIs to a form that allows read-write access. > If you do not have a Gerrit account, you should get one immediately! When > you select the SSH (read-write, Gerrit) choice, a new variable prompt, > Eclipse Git/Gerrit user ID, will appear at the very bottom. Here you should > enter your Eclipse account ID, e.g., for me, emerks Thanks. >. Note that if you find > it very painful to change each of the many URIs in the dialog, you'll only > ever have to do this once, because the installer will remember this choice > and will no longer display the variable, unless you check Show all > variables, in which case you can change the choice you made previously. It is very painful indeed. Especially that on Linux the drop-down jumps frequently away from my mouse pointer. One of these SWT Linux issues which makes Oomph less fun to to use. I try to capture it, but so far it refuses to show up on a recording.
Created attachment 280657 [details] Jumping popup If I don't record almost every access leads to the popup jumping around.
(In reply to Lars Vogel from comment #31) > Created attachment 280657 [details] > Jumping popup > > If I don't record almost every access leads to the popup jumping around. That looks annoying. Do you think the SWT folks can fix such a GTK-specific problem related to org.eclipse.swt.widgets.Combo? I doubt it's a problem in org.eclipse.jface.viewers.ComboViewer which is what we're using.
(In reply to Ed Merks from comment #32) > (In reply to Lars Vogel from comment #31) > > Created attachment 280657 [details] > > Jumping popup > > > > If I don't record almost every access leads to the popup jumping around. > > That looks annoying. Do you think the SWT folks can fix such a GTK-specific > problem related to org.eclipse.swt.widgets.Combo? I doubt it's a problem in > org.eclipse.jface.viewers.ComboViewer which is what we're using. I have never seen this with Combos or ComboViewers in our SDK, so reproducing this outside Oomph will be difficult for me. SWT typically fixes things if they have an isolated reproducer.
(In reply to Lars Vogel from comment #33) > I have never seen this with Combos or ComboViewers in our SDK, so > reproducing this outside Oomph will be difficult for me. SWT typically fixes > things if they have an isolated reproducer. The last time I invested a day of effort with regard to reproducing a GTK-specific problem reported by you, it was quickly returned as a duplicate and then finally dismissed as a crappy GTK version, so I won't be investing such an effort again any time soon.
(In reply to Lars Vogel from comment #30) > I once joined a presentation from you in which you said, Oomph makes reading > the instructions unnecessary. > Lars, I wrote a tutorial describing the end-to-end process involved. I would hope that people read it, but I know that people rarely look closely at anything that is presented to them. In any case, you were presented with combo boxes with choices, each with descriptive labels telling you what choices are available. You are a platform developer and I expect you know what URIs you use when you clone manually. But you didn't read, *and* you didn't look at the choices, accepting the defaults. That's all find of course and that works too. So yes, you didn't need to read anything nor even make any choices, did you? Ergo, no instructions were necessary. But when there are choices, you might want to consider them, especially if you don't like the default. If you don't understand the choices, you might then optionally want to read about it, which is the point of having a tutorial that you are not required to read. > It is very painful indeed. Especially that on Linux the drop-down jumps > frequently away from my mouse pointer. One of these SWT Linux issues which > makes Oomph less fun to to use. I try to capture it, but so far it refuses > to show up on a recording. Well, it's a one time pain and that pain is way below the pain threshold of getting even a single platform Git repository into your workspace in an error free state (without reading copious instructions, if you know where to even find them).
(In reply to Ed Merks from comment #35) > (In reply to Lars Vogel from comment #30) > > I once joined a presentation from you in which you said, Oomph makes reading > > the instructions unnecessary. > > > > But you didn't read, *and* you > didn't look at the choices, accepting the defaults. That's all find of > course and that works too. So yes, you didn't need to read anything nor > even make any choices, did you? Ergo, no instructions were necessary. Choices are not visible by default, ergo I did not see them. I have to select "See all variables." I suggest to make all important setting visible to the user, if that is possible. Also I don't think a user is likely to select Gerrit ssh or HTTP per repo, so if that is possible in Oomph, I would suggest to have only one option which kind of access should be used and to re-use it for all repos. Can I instruct Oomph to use my existing Git repo? I like to reuse the EGit default ~/home/git After testing Oomph I have several times clone all repos on disk
(In reply to Lars Vogel from comment #36) > Choices are not visible by default, ergo I did not see them. I have to > select "See all variables." > They were all visible the first time you walked through this process. Once you've made your choices *and* proceeded, the choices are remembered; remembered settings are not presented by default which you can of course change via the checkbox. > I suggest to make all important setting visible to the user, if that is > possible. All settings important and are visible to the user, they're just not repeated every single time because that's a boatload of information to repeated represent choices that have already bee made. > Also I don't think a user is likely to select Gerrit ssh or HTTP > per repo, so if that is possible in Oomph, I would suggest to have only one > option which kind of access should be used and to re-use it for all repos. > Yes, that would be nice to have. > Can I instruct Oomph to use my existing Git repo? Yes, you had a choice initially (Git clone location rule) for how to structure your git clones, i.e., where to put them. You opted for the default; you can change that setting if you like. > I like to reuse the EGit > default ~/home/git After testing Oomph I have several times clone all repos > on disk It's a bad pattern but it's available to you, and I'm sure nothing I could say would sway that thinking, i.e., the clone might be dirty, it might be on another branch, it might be already used in another workspace, and so on.
(In reply to Ed Merks from comment #37) > > They were all visible the first time you walked through this process. Once > you've made your choices *and* proceeded, the choices are remembered; > remembered settings are not presented by default which you can of course > change via the checkbox. I don't remember having ever seen that but initially I was fighting with the broken DnD support under Linux, so I might have had my mind somewhere else. Thanks for clarification. > > Can I instruct Oomph to use my existing Git repo? > > Yes, you had a choice initially (Git clone location rule) for how to > structure your git clones, i.e., where to put them. You opted for the > default; you can change that setting if you like. Cool, even though my desired option seems unavailable. Why would I ever clone in a folder with the branch name? Except that is brings up CVS memories. ;-) I see twice the same entry in the Git clone location rule: "Located in a folder...." Maybe you can replace one of them with a rule without the branch? > > I like to reuse the EGit > > default ~/home/git After testing Oomph I have several times clone all repos > > on disk > > It's a bad pattern but it's available to you, and I'm sure nothing I could > say would sway that thinking, i.e., the clone might be dirty, it might be on > another branch, it might be already used in another workspace, and so on. No it is not a bad pattern to clone a repo only once.
Created attachment 280658 [details] Twice the same entries See screenshot for the identical entries.
(In reply to Lars Vogel from comment #39) > Created attachment 280658 [details] > Twice the same entries > > See screenshot for the identical entries. If you look closely you see that the first entry uses a dash character to separate repo and branch, while the second entry uses a slash, which creates an additional sub directory for the branch.
(In reply to Lars Vogel from comment #38) > (In reply to Ed Merks from comment #37) > > > Can I instruct Oomph to use my existing Git repo? > > > > Yes, you had a choice initially (Git clone location rule) for how to > > structure your git clones, i.e., where to put them. You opted for the > > default; you can change that setting if you like. > > Cool, even though my desired option seems unavailable. Why would I ever > clone in a folder with the branch name? Except that is brings up CVS > memories. ;-) > Keep in mind that Oomph was developed in the days when there were commonly maintenance branches (for a full year) and one generally had a specialized development environment for the maintenance branch that was different than the one for the master branch, i.e., different IDE version, different target platforms, different API baselines, and of course different checked out branches in "the clone". Hence the need for multiple clones and the flexibility of where to put them and how to name them. In any case, the existing last choice would already allow you to reuse an existing clone, but with a choice per-repo. Via this commit I've added the choice for an "qualified" repo name: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=6b0882811d523bcae2aa637ebf916302293bdd3c Choosing this then introduces a prompt for the root folder in which to put all the clones, if you want ~/git you'll have to add the /git to the default. > I see twice the same entry in the Git clone location rule: "Located in a > folder...." Maybe you can replace one of them with a rule without the > branch? > > > > I like to reuse the EGit > > > default ~/home/git After testing Oomph I have several times clone all repos > > > on disk > > Of course the counter point is that you have the advantage that you can delete your entire folder to delete the installation, git clones, and workspace, and when you test, you test with a clean clone so you know how this works for a user using this from scratch. > > It's a bad pattern but it's available to you, and I'm sure nothing I could > > say would sway that thinking, i.e., the clone might be dirty, it might be on > > another branch, it might be already used in another workspace, and so on. > > No it is not a bad pattern to clone a repo only once. As I said, I'm sure nothing I could say would sway your thinking.
Note that the latest version of the installer now support changing all the Git repository URLs via a single variable: https://wiki.eclipse.org/images/f/f4/Oomph_Installer_Advanced_Platform_SDK_Variables_With_Style_Prompt.png That's documented in this section: https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning#Review_the_Variables
I don't know if this is a real issue or intentional but the Launch-Config is missing e4.core.tools feature so no E4 Editor was available in my testing.
I've updated it to include that feature: https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=3d523e32ffd4f41fb44dd8feb9ac9d1a30dac527
I think a commit in bug 576432 caused a regression for the Eclipse Platform SDK Provisioning, the same as reported in bug 458500. At least I got the same error message as in the latter bug when I tried the instructions today. An improvement would be to be able to specify an initial branch for the provisioning (e.g. "R4_20_maintenance") to avoid having to rely on master being in a good state. Alternatively, maybe there could be a test that verifies that the provisioning works for master?
(In case anyone else encounters the issue in comment 45 before it's fixed, I could work around it by clicking Back, then manually deleting platform-sdk/git/eclipse.jdt.ui/.project, then restarting the startup tasks with Finish.)
