-
-
Notifications
You must be signed in to change notification settings - Fork 19
Repository api
Google group thread.
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.
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).
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".
The module is an unique name that identifies a project, library or piece of code. Maven uses the alternative wording "groupId".
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
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".
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 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()) {
// ...
}
}