[forge-dev] How should plugins keep up with api updates

[Lincoln Baxter, III]

> You can find the complete discussion in the logs:
> http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2012/forge.2012-05-30-14.03.log.html.
> By the way why was there no email send around with this info? Isn't this
> supposed to happen automatically?
>

I have been creating the meeting notes by hand every week :) nothing
automatic, unfortunately, though that would be nice.


> The summary is that there are 2 aspects to this problem:
> 1. When installing a Forge plugin, the correct version of this plugin,
> compatible with the runtime that is requesting the install should be
> selected
>

This is currently selected by the Branch or Tag of the plugin.


> 2. When launching a Forge runtime, the plugins that are not compatible
> with the runtime that is launched cannot be enabled
>

This is currently done by detecting the version of the Forge API used by
the plugin at runtime - however, this does not directly correlate to #1.


>
> AFAIK both aspects have been addressed to some extent but the discussion
> proves that there is room for improvement. This email thread is the place
> where we can continue this discussion and maybe hash out some JIRA issues.
>
>
> As I understand,  FORGE-584 was due to the fact that the plugin referenced
> version 1.0.0-SNAPSHOT of the Forge API in the 1.0.2.Final branch of the
> plugin. It is not abnormal that this does not work. The plugins should be
> compatible at runtime but not necessarily building with the latest and
> greatest version of the Forge API. So this was IMO a bug in the plugin code
> where the plugin writer had not properly updated the dependencies in one
> (or more) branch(es). I believe we already had this discussion before and I
> really don't see a way to make this updating process go smoother. Ideas
> here are more than welcome.
>

Correct - the plugin was referencing a now very old version of the API
(which should not have broken, but had to be broken to support some
critical fixes. There will be no more API breakage - this should no longer
be a problem)


>
> To address the second aspect above, it is a bit awkward to have to
> reinstall all the plugins when the runtime is for example updated from
> version 1.0.6.Final to 1.1.0.Final. And what if you need to maintain 1.0.x
> and 1.1.x at the same time? To address these problems I see 2
> possibilities. The first is to allow multiple versions of plugins to be
> installed next to each other and the runtime will select the most
> appropriate version when it starts. When the compatible version of an
> already existing plugin is not available, Forge could ask the user if it
> can be installed automatically, thus addressing the manual reinstall
> mentioned earlier. The second solution would be that every runtime has its
> own location to install plugins and comes already bundled with a number of
> 'blessed' plugins, much like the Eclipse way of doing stuff. Again, ideas
> more than welcome.
>

We certainly need a strategy for this. As you said, ideas welcome :)


>
> WDYT?
>
> Cheers,
> Koen
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120531/a29a01d7/attachment.html