4:58 p.m.
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/for....
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