12:38 a.m.
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?
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."