[forge-dev] [JBoss JIRA] Commented: (SEAMFORGE-23) Forge needs a de-centralized plugin distribution and repository system

Dominik Obermaier (JIRA) jira-events at lists.jboss.org
Tue Jun 28 19:35:23 EDT 2011


    [ https://issues.jboss.org/browse/SEAMFORGE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611656#comment-12611656 ] 

Dominik Obermaier commented on SEAMFORGE-23:
--------------------------------------------

I think a good idea for this could be the Homebrew appraoch (https://github.com/mxcl/homebrew). They have a so called "formula" directory in their github project. Essentially they just are instructions how to download and build things. My idea for a Seamforge Plugin Directory would be the following:

1. Create a Github Project with Seamforge Plugin "Formula"
2. Every known Seamforge Plugin gets an own formula file. In this formula file, there is information about the plugin like name, description, download URL, authors,....
3. When searching for plugins, seamforge checks out the github project and scans for formulas. (I do not know how the Homebrew guys implemented their mechanism, but we could check that out) Then the can display all the plugin information.
4. When a user wants to install a plugin, the installation instructions in the formula file will be followed by seamforge and it installs the plugin.


This has several advantages:

- We could provide information in the formula, which Maven artifact has to be downloaded and in which repository this plugin is located
- We are not locked in to Maven, because a Plugin Developer could just release binaries of his/her plugin and Seamforge could download it via normal http download.
- If there are snapshot versions of a plugin, then this could be described in the formula, too and the user can instruct seamforge to utilize maven and build the plugin from source.
- We have a stable hoster for the index of the plugins.
- Literally everyone can contribute plugin formulas via pull-requests. So if a plugin author wants to make his/her plugin public, he/she just writes the formula file and makes a pull request. And if this is just an alpha plugin, then the author does not have to care about releasing the plugin to a Maven repository, because seamforge could build the plugin (via maven) from source and install it.


> Forge needs a de-centralized plugin distribution and repository system
> ----------------------------------------------------------------------
>
>                 Key: SEAMFORGE-23
>                 URL: https://issues.jboss.org/browse/SEAMFORGE-23
>             Project: Seam Forge
>          Issue Type: Feature Request
>          Components: Brainstorming, Plugin API
>    Affects Versions: 1.0.0.Alpha1
>         Environment: All
>            Reporter: Lincoln Baxter III
>            Priority: Critical
>              Labels: Maven
>
> There is no disputing the value of this type of feature, as has been shown with App-stores of all kinds. This would be relatively simple to implement as a Maven-based system, delegating all of the artifact resolution and dependency management to Maven.
> Features Forge would need to provide:
> 1) Built-in plugins and native APIs to search/install/remove/update plug-ins (easy using forge Resource APIs + Aether to add/remove JARs.) This internal plugin/commands could be called "forge" for simplicity
> ------------------------------------------------------------------------------------------
> $ forge plugin-find prettyfaces
> Forge found the following plugins in specified repositories:   <--- notice the 'forgeplugin' classifier used to identify forge plugins from other artifacts.
>  * http://ocpsoft.com/repository ...... [prettyfaces] com.ocpsoft.pretty.faces:prettyfaces-forgeplugin:[... 3.1.0, 3.2.0, 3.2.1]
>  * http://repo1.maven.org/ .............. [prettyfaces] com.ocpsoft.pretty.faces:prettyfaces-forgeplugin:3.1.0
> $ forge plugin-install prettyfaces --version 3.1.0
> ***SUCCESS*** [prettyfaces] plugin was successfully installed. You will need to restart forge to see these changes.
> $ forge plugin-list
> Listing installed plugins:
>  * prettyfaces [3.1.0]
>  * forge-scaffold [1.0.0.Alpha1]
>  * forge-javaee6 [1.0.0.Alpha1]
>  * home-control [1.0.0.Alpha1]
> $ forge plugin-remove prettyfaces 
> Are you sure you you want to remove the plugin(s) [prettyfaces] [Y,n]? Y
> ***SUCCESS*** [prettyfaces] plugin was successfully removed. You will need to restart forge to see these changes.
> ------------------------------------------------------------------------------------------
> 2) Plugin repository management (add/remove/edit/list current plugin repository targets.)
> ------------------------------------------------------------------------------------------
> $ forge repo-list
> Currently using the following plugin repositories:
>  * 1. https://repository.jboss.org/nexus/content/groups/public/
>  * 2. http://ocpsoft.com/repository
>  * 3. http://example.com/forge/plugin-repository
> $ forge repo-add http://jboss.org/forge/repository/   <-- These two will be KEY, we NEED THESE to happen
> $ forge repo-add http://javaee.org/forge/repository/ 
> $ forge repo-list
> Currently using the following plugin repositories:
>  * 1. https://repository.jboss.org/nexus/content/groups/public/
>  * 2. http://ocpsoft.com/repository
>  * 3. http://example.com/forge/plugin-repository
>  * 4. http://jboss.org/forge/repository/
>  * 5. http://javaee.org/forge/repository/ 
> $ forge repo-del 5
> ***SUCCESS*** removed repository [http://javaee.org/forge/repository/]. Plugins installed from this repository will no longer be auto-updated, and can be removed using [forge plugin-remove {plugin-id}]
> ------------------------------------------------------------------------------------------
> 3) Auto-update functionality
> Periodically search for updates to existing plugins (or search on request) - ask users if they would like to see a list of updates or perform an automated update / update individual plugins.
> 4) A meta-data system of identifying compatible versions of plugins w/running version of forge. 
> Possibly need to create a maven packaging type and build plugin in order to facilitate this type of additional metadata and artifact resolution. (Or could require a <classifier>forgeplugin</classifier>. We already have the maven GAV (GroupId : ArtifactId : Version) information. Supplemented with this classifier, we could easily identify forge plugins from other artifacts in maven.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the forge-dev mailing list