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

[Lincoln Baxter, III]

On Wed, May 30, 2012 at 6:18 PM, Burr Sutter <bsutter at redhat.com> wrote:

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

What do you mean by plug-in dependencies? What drives you 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.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?
> >>
> >> 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >>
> >
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
> _______________________________________________
> 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/6336fc2a/attachment-0001.html