On 03/15/2013 04:19 AM, Pascal
Rapicault wrote:
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.
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.
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
The next thing I envisioned with this was to allow p2 to directly call to a search engine when missing capabilities were found.
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).
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.
|