| Re: [cross-project-issues-dev] Request for comment: Provide standard update site locations |
|
On 03/15/2013 04:19 AM, Pascal
Rapicault wrote:
That makes total sense. Generation of a minimal companion file should be made default by p2/Tycho publisher. One could override or delete it if necessary.A while back I started some work on this particular issue but never took it to fruition (just lack of time). The initial predicate is that since search engines are good at helping us find stuffs, we should use them rather than building another mechanism. Since the p2 repos are not search engine friendly, what I had done consisted in generating a companion file that listed all the capabilities provided by a repository. Once these would be indexed by the search engine, then people would be able to search for those capabilibies (e.g. org.eclipse.emf 2.9) and be provided with the URL of a p2 repo. FYI, for JBoss Tools, we have a Mojo generating such an index that for Tycho "eclipse-repository" packaging type: https://github.com/jbosstools/jbosstools-maven-plugins/wiki I'm afraid this will introduce more difficulty: a project usually maintains multiple repositories for different versions and different "quality level" (eg release, milestone, integration, snapshot). Choosing the right repository is something that requires some understanding about how the project to consume is organized, which totally changes from a project to another (and even from a version of a project to another).The next thing I envisioned with this was to allow p2 to directly call to a search engine when missing capabilities were found. It seems to me that choosing the right repo is something that really requires some human skills (such as asking questions to forums) to be executed correctly. I wouldn't trust a bot for that. If we could enforce a standard structure for p2 repositories, that would help to automate seeking a repository; but history has shown that it's not easy to find a layout that applies well to all projects since there can be some big differences: * Does project actually build sources to produce a repo or does it aggregate from multiple repo? * Does project maintain some old branches or only the newest one? * How many levels of quality does the project have? (so I've seen several values between 2: just snapshot and release; and 5: snapshot, integration, milestone, release candidate/staging, release...) * ... This makes me believe that there is not a single governance pattern for a project and p2 repositories, and that it's impossible to implement it in a p2-guess-the-right-repo feature. |