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

Well said Thomas - I am a great "dumb user" and plug-in dependencies drive me nuts.

On May 30, 2012, at 5:58 PM, Thomas Frühbeck wrote: > IMHO there are two sides to this: > 1) how much will the average developer invest in using plugin > management capabilities - however useful - in Forge > 2) if there is only limited support for plugin management, will the > experienced programmer recognize it > > The more Forge matures and plugins get written it is an important > functionality to be able to _manage_ plugins. There will always be > plugins lagging a bit behind, although they are useful to the > developers. I think it is a very important for users of Forge to have > control over the lifecycle of their plugins. > I remember that when I started to use Forge many plugins were up-to-date > with the latest core version, but shortly afterwards a change in the API > made some work, some break. > > To me plugin management could mean: > - presentation of installed plugins > - marketing of updated versions > - lifecycle management of plugins like versioning, update, rollback > > As a dumb user of Eclipse I cannot say how much control I have over the > different versions of plugins I have/had installed. Most of my collegues > tend to praise the lord for a working featureladen installation, because > the interdependencies make it difficult - for us - to _manage_ it. > Mostly we dump it and make a new installation. > Some even have 5+ installations in parallel for the many different > projects they have to service. > > Forge is a developer tool, and therefore it should support a wide range > of use cases in a multi-module / multi-version scenario. > I am convinced that Forge has the potential to grow up to this, but it > seems a long way to go.. > > Thomas > > Am 30.05.2012 21:34, schrieb Koen Aers: >> Hi Folks, >> >> The Forge meeting today started off with a discussion spawned by this JIRA issue:https://issues.jboss.org/browse/FORGE-584. >> >> You can find the complete discussion in the logs: http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2012/forge.20.... By the way why was there no email send around with this info? Isn't this supposed to happen automatically? >> >> 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 >> 2. When launching a Forge runtime, the plugins that are not compatible with the runtime that is launched cannot be enabled >> >> 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. >> >> 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. >> >> WDYT? >> >> Cheers, >> Koen >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev