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

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

Lincoln, are you one of those lucky guys who don't have to hassle regularly with incompatible plugins in Eclipse? Just a hint: - I tried to install JBoss Tools 32bit into classic Eclipse 32bit on Win7 - it failed in the middle of installing ??? - SVN: there are two prominent plugins, incompatible, one looking half way like the other but handling is very different in the hard cases, PITA from start to end, I see myself reverting regularly to the command line - for some time recently I couldn't update my m2e plugin because it carried a dependency to a something in version 1.1 which was not released yet ??? Have a look at the different flavors Eclipse IDE bundles - to me the main reason for those is: plug-in (inter-) dependencies and plug-in management. I don't want to complain, but to me these are the everyday problems I face _after_ I told my boss that the fix xxx will only take an hour :-/ (The fix itself may take 5 minutes, the rest of the day it will take to get the infrastructure of the project up and running again.) And then we are programmers open for the newest, latest, greatest. And of course any author of a plugin would want his customers to pick up the new functionality ASAP. So I think one core features is a stable, manageable plugin life cycle. Thomas Am 31.05.2012 07:40, schrieb Lincoln Baxter, III: On Wed, May 30, 2012 at 6:18 PM, Burr Sutter <bsutter(a)redhat.com&gt; 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? _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Hi Lincoln, Plugin dependencies could become a reality very soon. Imagine a plugin that adds a facet to a project that is being used by yet another plugin… Cheers, Koen Op 31-mei-2012, om 08:30 heeft Lincoln Baxter, III het volgende geschreven: > Ah, you were talking about eclipse. Yes, this makes sense. It's painful. I was confused because Forge currently doesn't have any plugin dependencies. > > On Thu, May 31, 2012 at 2:22 AM, Thomas Frühbeck <fruehbeck(a)aon.at&gt; wrote: > Lincoln, > are you one of those lucky guys who don't have to hassle regularly with incompatible plugins in Eclipse? > Just a hint: > - I tried to install JBoss Tools 32bit into classic Eclipse 32bit on Win7 - it failed in the middle of installing ??? > - SVN: there are two prominent plugins, incompatible, one looking half way like the other but handling is very different in the hard cases, PITA from start to end, I see myself reverting regularly to the command line > - for some time recently I couldn't update my m2e plugin because it carried a dependency to a something in version 1.1 which was not released yet ??? > > Have a look at the different flavors Eclipse IDE bundles - to me the main reason for those is: plug-in (inter-) dependencies and plug-in management. > I don't want to complain, but to me these are the everyday problems I face _after_ I told my boss that the fix xxx will only take an hour :-/ (The fix itself may take 5 minutes, the rest of the day it will take to get the infrastructure of the project up and running again.) > > And then we are programmers open for the newest, latest, greatest. And of course any author of a plugin would want his customers to pick up the new functionality ASAP. > So I think one core features is a stable, manageable plugin life cycle. > > Thomas > > Am 31.05.2012 07:40, schrieb Lincoln Baxter, III: >> On Wed, May 30, 2012 at 6:18 PM, Burr Sutter <bsutter(a)redhat.com&gt; 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? >> >> > > > _______________________________________________ > 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." > _______________________________________________ > 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

yes, this is not unique to eclipse (and even though eclipse have full osgi model under it is still a nightmare) - and I would be really interested in how you would avoid plugin interdependencies at Forge going forward ? Don't you expect others to depend on each other and build on top ? /max On May 31, 2012, at 9:56 , Koen Aers wrote: > Hi Lincoln, > > Plugin dependencies could become a reality very soon. Imagine a plugin that adds a facet to a project that is being used by yet another plugin… > > Cheers, > Koen > > Op 31-mei-2012, om 08:30 heeft Lincoln Baxter, III het volgende geschreven: > >> Ah, you were talking about eclipse. Yes, this makes sense. It's painful. I was confused because Forge currently doesn't have any plugin dependencies. >> >> On Thu, May 31, 2012 at 2:22 AM, Thomas Frühbeck <fruehbeck(a)aon.at&gt; wrote: >> Lincoln, >> are you one of those lucky guys who don't have to hassle regularly with incompatible plugins in Eclipse? >> Just a hint: >> - I tried to install JBoss Tools 32bit into classic Eclipse 32bit on Win7 - it failed in the middle of installing ??? >> - SVN: there are two prominent plugins, incompatible, one looking half way like the other but handling is very different in the hard cases, PITA from start to end, I see myself reverting regularly to the command line >> - for some time recently I couldn't update my m2e plugin because it carried a dependency to a something in version 1.1 which was not released yet ??? >> >> Have a look at the different flavors Eclipse IDE bundles - to me the main reason for those is: plug-in (inter-) dependencies and plug-in management. >> I don't want to complain, but to me these are the everyday problems I face _after_ I told my boss that the fix xxx will only take an hour :-/ (The fix itself may take 5 minutes, the rest of the day it will take to get the infrastructure of the project up and running again.) >> >> And then we are programmers open for the newest, latest, greatest. And of course any author of a plugin would want his customers to pick up the new functionality ASAP. >> So I think one core features is a stable, manageable plugin life cycle. >> >> Thomas >> >> Am 31.05.2012 07:40, schrieb Lincoln Baxter, III: >>> On Wed, May 30, 2012 at 6:18 PM, Burr Sutter <bsutter(a)redhat.com&gt; 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? >>> >>> >> >> >> _______________________________________________ >> 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." >> _______________________________________________ >> 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

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