Community
Participate
Working Groups
Projects that are using Git repos in releng builds need Git implementation of the IFetchFactory to start generating values for the source references. This can possibly be also addressed on bug 289838. Egit also needs to implement IBundleImporterDelegate for the UI extension point More information on the Eclipse-SourceReferences can be found here http://wiki.eclipse.org/PDE/UI/SourceReferences
This will be looked at in 0.12 with the rest of PDE stuff.
Some discussion on bug 345670 comment #4 about how the syntax (which is based on the maven syntax) could look. PW
Is there a timeframe for the implementation of this feature? We have started building some projects from git starting today and now their source references in the manifests will be broken. It would be nice if this could be fixed so our SR1 bundles still retain their source references :-) Willing to send chocolate for bug fixes...
The git fetch factory currently generates a source header: Eclipse-SourceReferences: scm:git:git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git;path="bundles/org.eclipse.ui.workbench";tag=v20110712-1754 which looks fine. We're still trying to figure out if we want to use one tag for the repo for the build and propagate that to the source header, bug 351819 PW
We should prefer to use http rather than git for the checkouts. There's no performance degredation these days on using http instead of git, and it's more universally accessible behind firewalls and the like. This may be something that can be changed at build time instead of needing the fetch factory to handle specifically though. Also, we shouldn't be recording tags, we should be recording commit hashes. A commit hash will always be relevant; a tag may not be (especially if the set of tags haven't been cloned from a remote server).
Chris, do you still plan to work on this?
It's not on my priority list atm.
This should be addressed for Juno, otherwise the support to fetch the source for the SDK bundles will no longer work compared to Indigo.
From my point of view when we migrate Eclipse SDK bundles to Git repo, this issue is no more an enhancement request, but major regression for the Eclipse SDK user. So if Chris does not have it in the plan, is there any other EGit commiter who is going to work on it for Juno?
(In reply to comment #8) > This should be addressed for Juno, otherwise the support to fetch the source > for the SDK bundles will no longer work compared to Indigo. Just to be clear, it will also cease to work for Indigo SR1 because we have migrated the source for SR1 for most of Eclipse/Equinox.
Changing the severity. See comment 8, 9 and 10.
(In reply to comment #11) > Changing the severity. See comment 8, 9 and 10. Ping? What is the target milestone for it?
Double ping!
Just to remind, as Dani said in comment 8: "This should be addressed for Juno, otherwise the support to fetch the source for the SDK bundles will no longer work compared to Indigo."
Szymon, can you describe concretely what needs to be done here? Some things are unclear to me: 1) As mentioned in comment #4 we are already generating Eclipse-SourceReference headers. Are we asking for this format to be changed to http or left alone? 2) The other part is providing an IBundleImporterDelegate implementation. Now team.core provides a default class BundleImporterDelegate, which makes use of project sets to implement the import. Since eGit does provide a project set capability, it seems like eGit just needs a trivial subclass that lists the supported repository types. Is this all we're waiting for? It would be nice if bundle import delegate extensions could specify these two values programatically and not even need to write a line of code (specify repository type and list of supported repository values). This would also avoid them needing to depend on provisional API in team to implement this.
(In reply to comment #15) > 1) As mentioned in comment #4 we are already generating Eclipse-SourceReference > headers. Are we asking for this format to be changed to http or left alone? I think that as long as the format is compatible with the maven documentation (http://maven.apache.org/scm/git.html) or with its slight variation we agreed on (see bug 345670) it can be left alone. > 2) The other part is providing an IBundleImporterDelegate implementation. Now > team.core provides a default class BundleImporterDelegate, which makes use of > project sets to implement the import. Since eGit does provide a project set > capability, it seems like eGit just needs a trivial subclass that lists the > supported repository types. Is this all we're waiting for? The missing subclass of BundleImporterDelegate is one thing, another thing that comes to my mind is the fact that EGit's project set capability doesn't override #asReference(URI, String). It converts SCM URLs into reference strings used to load projects into the workspace. See bug 356448, it shouldn't be too hard either. > It would be nice if bundle import delegate extensions could specify these two values > programatically and not even need to write a line of code (specify repository type > and list of supported repository values). Good idea!
An additional complication to consider in the Git case is that multiple projects can share the same repo. When the user imports a single project, the implementation has to clone the whole repository, check out the right tag, and then import the project into the workspace. Now suppose the user tries to import a second project from the same Git repository. In this case, the repo has already been cloned and it can point to a different tag. You cannot simply switch the whole repo to another tag, since the user may already have applied changes in the first project (committed, staged, or even unstaged). The only thing you can do is to detect the problem and ask the user what to do. If the repo is already set to a tag or branch tip and has no uncommitted files, the user probably wants to switch to the latest of the possible tags, so this should be the pre-selected choice.
(In reply to comment #15) > It would be nice if bundle import delegate extensions could specify these two values > programatically and not even need to write a line of code (specify repository type > and list of supported repository values). This would also avoid them needing to depend on > provisional API in team to implement this. Filed bug 366790 for this. What you said about the provisional API is true, but still EGit will need to address bug 365425. Dropping 3.5 and moving to a newer version (preferably to 3.8) is a must in order to work with the extension point.
A possible solution, if EGit does not switch to Eclipse 3.8, see bug 365425, comment 5: > 2) Just add these extensions to egit.core manifest. AFAIK if there is no right > extension, they will be silently ignored. So for EGit on Eclipse prior to 3.8, > it would do nothing.
That would work for the extension point from o.e.team.core ie bundleImporters, but for the one from o.e.team.ui (scmUrlImportPages) a bundle dependency has do be specified as it requires an implementation of org.eclipse.team.ui.IScmUrlImportWizardPage. The good news is that in the latter case a dep on 3.7 should be enough.
See http://egit.eclipse.org/r/4899 Note that importing with a tag is not supported yet, see bug 367712. Hudson fails with "Missing requirement: org.eclipse.egit.core 1.3.0.qualifier requires 'bundle org.eclipse.team.core [3.6.100,4.0.0)' but it could not be found]", this is caused by bug 365425.
(In reply to comment #20) If this bug is blocked for Juno due to 3.5 compatibility issues, then please try to put the GitScmUrlImportWizardPage into a (new) fragment for org.eclipse.egit.ui. The fragment could have a dependency on 3.7.
(In reply to comment #22) > (In reply to comment #20) > If this bug is blocked for Juno due to 3.5 compatibility issues, then please > try to put the GitScmUrlImportWizardPage into a (new) fragment for > org.eclipse.egit.ui. The fragment could have a dependency on 3.7. I can't find the comment, but this is exactly what is going to happen. Tomek has been preparing an optional fragment for egit.ui with dependency to 3.7.
(In reply to comment #23) > Tomek has been preparing an optional fragment for egit.ui with dependency to 3.7. It has been submitted to Gerrit some time ago, see https://git.eclipse.org/r/#/c/4899/ , sorry for not updating the bug.
Could someone from EGit team look at the contribution. It's quite big and we should start reviewing it to make it part of the release in June. Thanks.
This changed as approved and supervised by the PMC.
merged as 64417af7a7e0d74ee423d6642d40a5116f584fe1 on stable-2.0
I verified that the initial Git import works using 3.8-I20120531-0600 and 4.2-I20120531-1500 together with the EGit RC2 support from http://download.eclipse.org/releases/staging/. However, there's a bug when trying a second import (bug bug 381321) and also the About info is wrong (bug 381319).
