SageTV Plugin Issues

[MrD]

Thought I would start a thread to capture plugin issues... if there is a better place for this feel free to move it.

Gemstone: The gemstone plugin downloads a lucene-core version 3.0.1 which usurps the v9 shipping lucene-core and causes Sage to get real angry and shutdown,

[stuckless]

That's a good idea to keep track of the plugin issues. FYI, the gemstome issue is really a phoenix issue, and I need to fix the plugin for Sage9 to not depend on lucene. Your post jogged my memory.

[Fuzzy]

Originally Posted by stuckless

That's a good idea to keep track of the plugin issues. FYI, the gemstome issue is really a phoenix issue, and I need to fix the plugin for Sage9 to not depend on lucene. Your post jogged my memory.

Are you going to have to separate out and make a new plugin entry for v9+ that just assumes lucene is available, since it's part of the 'core' now?

[MrD]

Funny... I was thinking the same thing; does the plugin system allow for versions of plugins pinned to a release of Sage?

[Fuzzy]

Originally Posted by MrD

Funny... I was thinking the same thing; does the plugin system allow for versions of plugins pinned to a release of Sage?

Pretty sure it doesn't.. but it does offer min and max version limits, so if the old one is modified to max out at 7.1.9.256, and the new one require 9.0.0, it should be okay.

[Slugger]

Nope. The plugin manager only allows a single version (the most recent) to be available for installation. It will be tricky to deliver a version of a plugin that requires lucene plugin on v7 but not include it in v9. Off the top of my head, I'd think you'd have to convince the owner of the lucene plugin to upgrade to the same level as v9 core is using such that the lucene plugin just replaces the core's lucene jar with itself when the plugin is installed. This way v7 can still use the plugin and v9 core isn't blown up by a different version of the lucene jar. I'm assuming whatever plugin(s) are using lucene can use whatever version the v9 core is using. If that's not the case then I don't think there are many options; certainly nothing popping into my head.

These ideas are all just that, ideas, and are untried/untested/unproven.

[Slugger]

Originally Posted by Fuzzy

Pretty sure it doesn't.. but it does offer min and max version limits, so if the old one is modified to max out at 7.1.9.256, and the new one require 9.0.0, it should be okay.

Hmm... yeah, excellent point. My only thought on that is now you end up with two lucene plugins, which sets a possibly ugly precedent going forward. Especially because now whatever plugin(s) depend on lucene will also have to be duplicated... a version of the plugin for v7 and then another manifest for v9. Then plugins that depend on those plugins need to be duplicated and so on.

Maybe we need a new/separate/isolated plugin repo for v9 and leave v7's alone?

[Fuzzy]

Or instead of maintaining that lucene is part of the core, we make the core automatically install the lucene plugin (which would be updated to use the newest version)

[Slugger]

Yup, that sounds like the answer to me. Any jar not called Sage.jar should be a plugin and the core just auto installs/updates whatever plugins it needs at startup.

The only issue with this is if the plugins using the older lucene can't use the newer version then you're breaking v7 plugins to make them work for v9. That would be my only argument for a new plugin repo (new major release, new, isolated plugin repo does have some merit in my books).

[Fuzzy]

We'd have to check, but i doubt there is much change in the 2.0.4 (which i seem to recall the current lucene plugin uses) and the current one, at least for the calls the sage plugins are likely to use.

[Fuzzy]

I'm curious how many plugins actually use the lucene besides phoenix anyway.

[stuckless]

Originally Posted by Fuzzy

I'm curious how many plugins actually use the lucene besides phoenix anyway.

I'm pretty sure it's just Phoenix... and if I recall it's only used in the MyMovies and DVDProfiler parts, and I'm doubtful that either of those 2 things are even used.

[Fuzzy]

Sounds like you've got some code to check... or deprecate...

[Narflex]

I wouldn't be against somebody hacking code into the plugin manager in SageTV that deals with the lucene dependency differently in V9. It was after all a core change that disturbed the plugin system...so it should be accounted for in there.

[Fuzzy]

Originally Posted by Narflex

I wouldn't be against somebody hacking code into the plugin manager in SageTV that deals with the lucene dependency differently in V9. It was after all a core change that disturbed the plugin system...so it should be accounted for in there.

Do you see any reason why core system files shouldn't be part of the plugin system as well? Even the sage.jar could have its own manifest, and the 'sagetv version' dependency changed to require a certain version of the sage core 'plugin'.

[tmiranda]

Originally Posted by Fuzzy

Do you see any reason why core system files shouldn't be part of the plugin system as well? Even the sage.jar could have its own manifest, and the 'sagetv version' dependency changed to require a certain version of the sage core 'plugin'.

I really like the idea of having Sage.jar as a plugin. This is where a lot of the changes will probably be made.

[stuckless]

Originally Posted by Fuzzy

Do you see any reason why core system files shouldn't be part of the plugin system as well? Even the sage.jar could have its own manifest, and the 'sagetv version' dependency changed to require a certain version of the sage core 'plugin'.

Originally Posted by tmiranda

I really like the idea of having Sage.jar as a plugin. This is where a lot of the changes will probably be made.

Personally I'm not a fan of have the SageTV Sage.jar has a plugin. I realize that this "might" appear to simplify updating the Sage.jar, but I think there are better ways to manage this, than adding Sage.jar as a plugin.

[tmiranda]

Originally Posted by stuckless

Personally I'm not a fan of have the SageTV Sage.jar has a plugin. I realize that this "might" appear to simplify updating the Sage.jar, but I think there are better ways to manage this, than adding Sage.jar as a plugin.

I'm certainly not the expert in this area and I am open to anything that will allow users to update the Sage.jar other than doing a complete reinstall.

[Fuzzy]

It wasn't so much as a method of 'simplifying' the update mechanism, but more of a method to centralize all the versioning into a similar system for all 'modules'. There also, currently, isn't any update available notification for the core sagetv program, and as far as I can recall, there never really has been one except for the forums. This would at least provide said notification. And really, it wouldn't be a manifest for sage.jar, but really for the whole sagetv core installation.

[stuckless]

Originally Posted by Fuzzy

It wasn't so much as a method of 'simplifying' the update mechanism, but more of a method to centralize all the versioning into a similar system for all 'modules'. There also, currently, isn't any update available notification for the core sagetv program, and as far as I can recall, there never really has been one except for the forums. This would at least provide said notification. And really, it wouldn't be a manifest for sage.jar, but really for the whole sagetv core installation.

Yeah, still think it's the wrong approach. SageTV will tell you when there is an updated STV, and I think that having a built in notification/updater, is great, I just don't think it should be a plugin, nor for the core jar. If it is, a a user disables the plugin, then what? What if separate plugin jars into a different directory than core jars... Do we start adding "if Sage.jar" code to the plugin manager?? I can see taking parts of NON critical pieces of SageTV and making it a plugin, like the ir tuners, or specific driver implementations for certain hardware, etc, but not the core itself.

Again, it just sounds like you want a better update mechanism, and I agree with that.