Repository api

A repository API for PDT extensions

Participants

• Martin Eisengardt
• Robert Gründler

Discussion

Google group thread.

Introduction

There are several repository arounds to find and load libraries, frameworks and others project fragments. Plugins need not ship those code fragments but instead should try to contact those repositories. This will help the plugin developers to concentrate on plugin functionality and there are no more new releases if only a new version of a php library is released.

The repositories should be usable by the plugin code and by the users through a browable repository tree view.

Wording

Repository

A repository is a single object instance that is aware of contacting a specific group of modules. It is associated by a repository URI (most of the time a http url).

Vendor

The vendor is the name of a module author. In several frameworks this may be replaced by a different wording, for example maven uses the wording "groupId". Pear uses the wording "pear channel".

Module

The module is an unique name that identifies a project, library or piece of code. Maven uses the alternative wording "groupId".

Version

The version number is used across nearly every repository system. The pdt extensions project does not care about a valid format. Although we suggest to use soem major common logic, for example semver

Files

The repository api supports several files. First of there is always a primary file that should represent a phar file with the major contents of the library. If an underlying repository system only supports single files there is no additional files. For example maven supports putting multiple files by using "classifiers".

Implementation

Extension point

To declare a new repository system the extension point org.pdtextensions.repos.factories must be used.

Schema: [https://github.com/pdt-eg/Core-Plugin/blob/master/org.pdtextensions.repos/schema/org.pdtextensions.repos.factories.exsd]

Extenders will have to implement the factory and provider interface: [https://github.com/pdt-eg/Core-Plugin/blob/master/org.pdtextensions.repos/src/org/pdtextensions/repos/api/IRepositoryProviderFactory.java] and [https://github.com/pdt-eg/Core-Plugin/blob/master/org.pdtextensions.repos/src/org/pdtextensions/repos/api/IRepositoryProvider.java]

There are three optional interfaces to access the repositories and they should be implemented if the underlying repository system supports it: [https://github.com/pdt-eg/Core-Plugin/blob/master/org.pdtextensions.repos/src/org/pdtextensions/repos/api/IVendorAwareProvider.java] [https://github.com/pdt-eg/Core-Plugin/blob/master/org.pdtextensions.repos/src/org/pdtextensions/repos/api/ITypeAwareProvider.java] [https://github.com/pdt-eg/Core-Plugin/blob/master/org.pdtextensions.repos/src/org/pdtextensions/repos/api/ITagAwareProvider.java]

Searching for a module programmatically

Searching for a module programmatically is done by the plugin activator [https://github.com/pdt-eg/Core-Plugin/blob/master/org.pdtextensions.repos/src/org/pdtextensions/repos/PEXReposPlugin.java] :

  final IFindResult result = PEXReposPlugin.getProvider.findModule("vendor", "module", "4.5.1");
  if (result.isOk()) {
    for (final IModuleVersion version : result.moduleVersions()) {
      // ...
    }
  }