Community
Participate
Working Groups
Currently as a result of our build, our bundle manifests contain references to the bundle source in the repository. For example: Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/eclipse:org.eclipse.ui;tag=v20110506-1500 We need to figure out what this will look like if we move to and build from Git repositories.
The syntax for maven's git repos is somewhat well defined, but they usually refer to a repo as a whole whereas this would need to refer to a folder inside. Suggest we have a ...;path= attribute on the end to specify where it comes from inside a repository.
Here's the maven documentation http://maven.apache.org/scm/git.html SCM Url For all URLs below, we use a colon (:) as separator. If you use a colon for one of the variables (e.g. a windows path), then use a pipe (|) as separator. The separator for the port has to be a colon in any case since this part is specified in the git URL specification. See man git-fetch. scm:git:git://server_name[:port]/path_to_repository scm:git:http://server_name[:port]/path_to_repository scm:git:https://server_name[:port]/path_to_repository scm:git:ssh://server_name[:port]/path_to_repository scm:git:file://[hostname]/path_to_repository Examples scm:git:git://github.com/path_to_repository scm:git:http://github.com/path_to_repository scm:git:https://github.com/path_to_repository scm:git:ssh://github.com/path_to_repository scm:git:file://localhost/path_to_repository
(In reply to comment #1) > Suggest we have a ...;path= attribute on the end to specify where it comes from > inside a repository. So based on our current map setup plugin@org.eclipse.platform.discovery.core=GIT,tag=v20101129-0900,repo=git://git.eclipse.org/gitroot/e4/org.eclipse.e4.search.git,path=bundles/org.eclipse.platform.discovery.core we could produce something like: Eclipse-SourceReferences: scm:git:git://git.eclipse.org/gitroot/e4/org .eclipse.e4.search.git:org.eclipse.platform.discovery.core;tag=v201011 29-0900;path=bundles/org.eclipse.platform.discovery.core PW
(In reply to comment #3) > we could produce something like: > > Eclipse-SourceReferences: scm:git:git://git.eclipse.org/gitroot/e4/org > .eclipse.e4.search.git:org.eclipse.platform.discovery.core;tag=v201011 > 29-0900;path=bundles/org.eclipse.platform.discovery.core I think it would need to be something like this (modulo text reflowing): Eclipse-SourceReferences: scm:git:git://git.eclipse.org/gitroot/e4/org .eclipse.e4.search.git;tag=v201011 29-0900;path=bundles/org.eclipse.platform.discovery.core;project=org.eclipse.platform.discovery.core The :org.eclipse.platform.discovery.core suffix (as part of the CVS syntax) is actually part of the Maven CVS syntax (says which folder to check out). However, with a Maven Git URL, you only have the path to the repository e.g. scm:git:git://git.eclipse.org/gitroot/e4/org.eclipse.e4.search.git So we'd then annotated it with ;tag=v20101129-0900 ;path=bundles/org.eclipse.platform.discovery.core ;project=org.eclipse.platform.discovery.core Though I think in the CVS parser, we assumed the project was the last part of the path - we could probably do the same here (e.g. if path.substr(path.lastIndexOf(/)).equals(project) then don't bother to tag the project). As a side note, it would be much, much nicer if we could switch to using HTTP instead of Git for the anonymous checkouts. Checking out over HTTP using the smart http server is now just as fast as Git, and doesn't involve any open ports to be viewed from behind HTTP proxies or firewalls. Given that a git: URL doesn't necessarily always translate to an http: URL just by changing the protocol, if we can generate it upstream using the HTTP checkouts that would be very advantageous to those who can't connect to Git protocol directly. So it would look like: scm:git:http://git.eclipse.org/gitroot/e4/org.eclipse.e4.search.git
(In reply to comment #4) > However, with a Maven Git URL, you only have the path to the repository e.g. > > scm:git:git://git.eclipse.org/gitroot/e4/org.eclipse.e4.search.git > > So we'd then annotated it with > ;tag=v20101129-0900 > ;path=bundles/org.eclipse.platform.discovery.core > ;project=org.eclipse.platform.discovery.core That looks good to me too. I would suggest we specify the project attribute deliberately, as I'd prefer to name things explicitly. Hopefully that would limit our chances of running into problems with it in the future, and simplify any programmatic validation we do. PW
Note that whilst CVS used the concept of 'project' to dictate what the file on the checked out filesystem was, Git has no such flexibility. So in CVS you can do 'cvs co -d bar modules/foo' and have 'foo' checked out into a directory called 'bar' - but in Git, your project is cloned and then has the 'path' which can't be renamed (Git doesn't have partial checkout). In other words, what are you intending to use 'project' for in this case? Defaulting to the project name in Eclipse if there isn't a bundles/org.eclipse.platform.discovery.core/.project file?
(In reply to comment #6) > In other words, what are you intending to use 'project' for in this case? > Defaulting to the project name in Eclipse if there isn't a > bundles/org.eclipse.platform.discovery.core/.project file? It would be the name of the project (no hunting around .project files) ... we have a number of cases where the path terminal directory in our SCMs don't match the directory it should appear as. PW
Right now I'm littering my git repo with tags like "v20110705-2054" on the last commit for each bundle that changed between this build and last build, so I can get unique qualifiers. Each date-time is calculated from the commit UTC timestamp. A - build commit - v<UTC1> B - changes ui.workbench - v<UTC2> C - changes jface - v<UTC3> D - changes ui.workbench E - changes ui.workbench F - changes jface G - last build commit v<UTC4> But to actually build I only needed v<UTC1> and v<UTC4>, and having source URLs with v<UTC1> would provide the correct specific version of all the plugins in the build. What if fed one build tag as the build input, and derived the tag/qualifier from the commit date/time. v<date-time>[a-z]? would be valid qualifiers for a given commit, and allowing the extra character at the end would satisfy our occasional need to bump up the qualifier for p2 without actually changing content. We would still allow a git tag to be used in the map file as a qualifier (so we support the existing state), but as bundles changed they would move to the new qualifier pattern + one repoTag build tag. This would all be done by an automatic tagging process at the beginning of the I build. We would be able to re-run builds by skipping the tagging and using an existing map. Please comment on the proposal. PW
There should be no reason to create tags automatically. This is unnecessary in a DVCS. The purpose of tagging in a CVS like structure was the only way to get a consistent view of the repository at that particular time. In Git, that's represented by the commit hash. So just record the commit has and not the tag, and anyone will be able to get exactly that version back again.
(In reply to comment #9) > The purpose of tagging in a CVS like structure was the only way to get a > consistent view of the repository at that particular time. In Git, that's > represented by the commit hash. So just record the commit has and not the tag, > and anyone will be able to get exactly that version back again. I have no real preference for repoTag. A commit hash would probably work just as well. Using a tag instead would allow that build commit to survive a lot of changes, like filter-branch, but we would hopefully not be doing that to a public repo. Of course as we just converted our repos from CVS and have no proof that they don't need some modification, we could potentially encounter that. The important part of the proposal is how the build input would interact with our map files/qualifier generation, as a build tag is just a human readable symbolic name for that commit hash. PW
FYI - bug 380872 and corresponding gerrit change https://git.eclipse.org/r/#/c/8154/ propose an Eclipse-SourceReferences generator for tycho. It adds header attributes: ;path="..." ;commitId=<SHA1_OF_HEAD> ;tag="<TAG_NAME_OF_HEAD>" (if a tag exists that points to HEAD only) if multiple tags point to HEAD, the first one in the tag list wins.
I can "see" these peeking in the MANIFEST.MF files of our "cbibased" test builds, so assume this is "all done" and just a matter of testing, to verify it works as expected, so ... I'll mark as fixed. To give an example, one I looked at was in o.e.ui.views: Eclipse-SourceReferences: scm:git:git://git.eclipse.org/gitroot/platfo rm/eclipse.platform.ui.git;path="bundles/org.eclipse.ui.views";tag="I 20130215-2011";commitId=493fef8670c05cb04055bdf84faee4848107d0b8
Verified in I20130227-2000.
