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

[Lincoln Baxter III (JIRA)]

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

Lincoln Baxter III commented on SEAMFORGE-23:
---------------------------------------------

Max,

Could you explain how you see that fitting in? I checked out the site but was not able to find much info about how to use it, what it actually does, etc...

http://www.eclipse.org/projects/project_summary.php?projectid=rt.equinox.p2

Would it work with Maven artifacts/dependency management? 

Also, yes; we could:

* Index assuming that we had control over the repository and it were dedicated to Forge plugins.
* Use our own packaging type (fpg) or something, for which the artifact would be a JAR (is this possible?), but run a nightly cron-job to scan through all the artifacts. 

Personally I think we need a repository of which we have complete control. The repository would be responsible for containing necessary metadata, much like an eclipse update-site. I would prefer not to implement a repository system myself, but I am assuming that we will need to in order to provide this functionality ...

Unless P2 works well enough that it would:

A) not require significant modifications to our architecture, and 
B) not require more work/time than creating a simple system ourselves.

> 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