Discussion: Plugin architecture changes

[stuckless]

I there is a discussion going on over in the SageTV Plugin Issues thread about issues with some plugins, but I'd this area to focus on how to we can change/enhance the plugin system.

Here are my thoughts...

I like the SageTV plugin model, but there are definately some things that I'd like to change

• jars added as dependencies not plugins
• plugins get their own plugin directory
• plugins jars loaded OUTSIDE of sagetv JARs
• multiple plugin repositories (ability to add repository URLs)
• Simplified plugin manifest
• Ability to publish using non-interactive means
• Ability to turn off MD5 checksum
• Scriptable (Jython, Groovy, JavaScript) plugins
• API to register new SageTV apis that are plugin scoped
• Who is going to "host"
• Do we care about S7 plugin compatibility?

Tom's List

• Right now a "General" Plugin can't contain an STVi component. This means if you want to have a plugin that uses the functionality available as a General (Standard) plugin and you want it to modify the STV, you need to make two plugins and have one as a dependency of the other.
• When a plugin is uninstalled I'd like to see all of the dependencies that are not needed for other plugins removed too.

Greg

• They should also have a well-defined place to store their configuration settings. This could be a separate .properties file, or a subtree of Sage.properties, but in either case all of a plugin's settings should be in one place where they can be exported or deleted as a unit by the plugin manager. This should be enforced by the API so that calls to Get/SetProperty are transparently redirected to the appropriate plugin property space.

jars added as dependencies not plugins
I think plugins should register their dependencies, as they do now, BUT, dependency .jar file files DO NOT have to be in the "SageTV plugin repository". Instead, jar files, would be downloaded via jcenter or maven central, on demand. MANY of the plugins that are in the SageTV plugin repository are in fact just repackaged jar files, etc, and it's quite tedious to update them

When multiple plugins depend on the same .jar dependency and they specify different versions, then the latest version is selected. IFa plugin specifies a Max Version for their jar dependency and the version that is selected is greater than their Max Version, then the plugin depending on the lesser version is disabled. We can probably notify the user at the time that they try to install the plugin that doing so would disable another plugin because of a version issue.

The goal here is to streamline the usage of .jar file dependencies and to make it consistent with existing java dependency models that are used in gradle, maven, ivy, etc, and it would turn make it easier for developer to manage their "real" plugin instead of a bunch of .jar files.

plugins get their own plugin directory
This is minor thing, but plugins have other related artifacts, and as such, I think that each plugin should be extracted into a separate plugin directory, and their artifacts contained in there as well. Plugins have the concept today of a resource area, but its optional, and there is no enforcement that a plugin actually use it. personally I'd like to see the plugin api extended with api calls for getCacheDir(), etc, that would return a cache specific location for a Plugin (probably under their plugin dir). In this way, cleaning up a plugin, and then mess of files they may leave behind, would be trivial... The plugin manager would delete the Plugin specific directory on removal.

plugins jars loaded OUTSIDE of sagetv JARs
I'd like dependency jar files to be put in a shared area, maybe, "JARsDEP". Plugins that ship a jar file as part of their activator would actually live in the plugin's specific directory. In no cases would I want to see anything actually contribute jar files to the main JARs area. SageTV JARs would always be loaded FIRST in the classpath and cannot be overridden. The plugin manager might actually validate this.

multiple plugin repositories (ability to add repository URLs)
Currently SageTV uses a single Plugin xml for all plugins plus a developer plugin xml. I'd rather see the ability to register multiple plugin repositories and sagetv would build a plugin xml from all the sources, in order. In that way developers could provide beta plugin repositories to users and simplify the process of testing/sharing plugins.

Simplified plugin manifest
I find it tedious to manage a Plugin's manifest. I'm not sure about the what to do about it... but I think I'd like to see a simplified model for building the manifest, etc. (And maybe this wouldn't such an issue, if all the .jar files are removed as plugins and treated as dependencies)

Ability to publish using non-interactive means
Today the publishing process for adding a new plugin or updating a plugin is very interactive with emails being used to validate, etc. I'd like to move to a more streamlined approach whereby a build system can actually publish plugins directly (as is done is most Maven projects). This makes it easy to keep plugins up to date. Personally the biggest reason I don't my plugins, very often, is the hassle of having to do it interactively.

Ability to turn off MD5 checksum
I think the MD5 check is great, but I also think it should be optional. There have been a few times when a remote system has somehow changed the MD5SUM of my jar, but, the jar file iteself has been fine. I think they were adding a signature to the file, which changes the MD5. I'd like the ability to "force" an install if that happens.

Scriptable (Jython, Groovy, JavaScript) plugins
Today, a plugin class has to be a Java class, and I'd like the ability to provide a Plugin class as JavaScript, Python, or Groovy.... with the requirement being that such a plugin would have to also dependon jython, groovy, etc. This would make it easier for non-java developers to contribute plugins using other scriptable languages. Once scripts are loaded in java, they are compiled and run as byte code, so there is not real performance issue for not doing this.

API to register new SageTV apis that are plugin scoped
It would cool if plugins could register SageTV API commands to the core SageTV. Plugins can kinda do this today, simply by being class file with static methods (I auto generate these classes in Phoenix), but it might be handy if plugins could simply register their API command, much like how sagetv does it internally. This would also enable scriptable plugins to register new APIs. The Plugin's start() method could actually manually register whatever APIs they want, and sagetv would auto-remove them when the plugin is deactivated.

Who is going to "host"
Google has already said that they are not going to release an open source product, and I'm wondering how plugins are going be managed, moving forward. ie, Do we still submit them like we do today, or should we go ahead with the Multi repository approach and we start to move away from the google hosted plugins?

Do we care about S7 plugin compatibility?
I think the question says it alll, but I'm curious as to whether or not S7 plugin compatibilty is an issue. ie, I think we'll be able to load S7 plugins, but, should we care if S9 plugins are compatible with S7?

[Fuzzy]

I feel the JARs as dependencies and not plugins might be a bit further than we need to go. If a plugin is manifested ideally, any jar's it depends on would be in a separate 'library' manifest, and would show up in a different section of the plugin manager. We might simply hide that tab in the manager by default. This would at least keep version tracking the same between STVI's, JARs, etc., all being within the same manifest system.

[Fuzzy]

Regarding S7 compatibility, if we do things right, I don't see a reason to focus too heavily on any new development working on the old versions. Upgrading SHOULD be painless, and free, once we work out the launchers and installation mechanics. I believe the only S7 functionality that isn't currently working on S9 is the SD EPG, which I believe Andy was going to be looking at in the near term. Once that is working, I don't see any reason for anyone to stay on S7, and that would get most the 'customers' on the same codebase.

[Fuzzy]

With multiple potential plugin manifests, it will likely be more of an issue actually keeping track and advertising what plugin sources are available. One option is to actually maintain the manifests (which are nothing more than xml files) in the git itself. This would of course require more people to be authorized to merge in pull requests, which would likely work if we branched 'master' development to a more community managed branch (instead of the google one which is only open to google employees).

[stuckless]

Originally Posted by Fuzzy

I feel the JARs as dependencies and not plugins might be a bit further than we need to go. If a plugin is manifested ideally, any jar's it depends on would be in a separate 'library' manifest, and would show up in a different section of the plugin manager. We might simply hide that tab in the manager by default. This would at least keep version tracking the same between STVI's, JARs, etc., all being within the same manifest system.

I think you've probably missed my point... which was having to create a plugin manifest for each jar file and each jar dependency is quite tedious. I own probably 50% (guessing) of the jar files dependencies in SageTV today, and how most of them get updated is that someone emails me an updated plugin manifest and asks that I update it... Again, having to repackage a jar file, and then add a sagetv specific manifest, just because you need to use it, is tedious, and it's the primary reason why I don't update to newer dependencies

Consider that with a typical Maven/Gradle/Ivy development environment where updating to a new dependency jar (and getting transitive jars) is as trivial as just changing the version number and re-run the build command. I tested 5 different versions of JOGL on the weekend in about 30 minutes, which is less time than it generally takes me to repackage a single jar file for SageTV plugin

[tmiranda]

Thanks for starting this thread. As somebody who has written a log of plugins I agree that some changes would be nice.

I would add to your list:

- Right now a "General" Plugin can't contain an STVi component. This means if you want to have a plugin that uses the functionality available as a General (Standard) plugin and you want it to modify the STV, you need to make two plugins and have one as a dependency of the other.

- When a plugin is uninstalled I'd like to see all of the dependencies that are not needed for other plugins removed too.

I agree with most of what you have suggested and have a few comments:

- I see no need to simplify the manifests. They are very straight forward now.

- I think v9 should run v7 plugins but v9 plugins do not necessary have to work on V7. This is already taken care of by the MINVERSION tag in the manifest.

- Mutiple repositories is something I've wanted for a long time. I think this can actually be done in the STV and may not require any core changes at all. I'll look at that in the next few days.

- I don't understand the usefulness of registering plugin APIs with the core. Why would the core need to know this?

[stuckless]

Originally Posted by tmiranda

Thanks for starting this thread. As somebody who has written a log of plugins I agree that some changes would be nice.

I would add to your list:

- Right now a "General" Plugin can't contain an STVi component. This means if you want to have a plugin that uses the functionality available as a General (Standard) plugin and you want it to modify the STV, you need to make two plugins and have one as a dependency of the other.

- When a plugin is uninstalled I'd like to see all of the dependencies that are not needed for other plugins removed too.

I agree with most of what you have suggested and have a few comments:

- I see no need to simplify the manifests. They are very straight forward now.

- I think v9 should run v7 plugins but v9 plugins do not necessary have to work on V7. This is already taken care of by the MINVERSION tag in the manifest.

- Mutiple repositories is something I've wanted for a long time. I think this can actually be done in the STV and may not require any core changes at all. I'll look at that in the next few days.

- I don't understand the usefulness of registering plugin APIs with the core. Why would the core need to know this?

I've added you 2 additions to the main post, since I fully agree with them.

The simplify the manifest is probably closer to your second point. ie, simplify "what is a plugin". For jar files, maybe it's a matter that the "manifest" is IN the jar, and not a .jar + manifest in another zip... it's that type of stuff when I say "simplify".

- I think v9 should run v7 plugins but v9 plugins do not necessary have to work on V7. This is already taken care of by the MINVERSION tag in the manifest.

So you are advocating that we NOT change the plugin structure. Or if we do, then we'll have to remember to use MINVERSION.

I don't understand the usefulness of registering plugin APIs with the core. Why would the core need to know this?

The plex plugin is a good use case for this. Today, they rely on a hack in the sagex-apis to register a new API that can be invoked via a URL, but that same API cannot be called from the STV (should it be needed). So consider if you will that instead, the plex plugin, pushed a javascript plugin that contained the FindMediaFileForFilename api. From the remote apis, nothing changes, and it can be accessed by name, just like any other SageTV api, but it also has the added benefit of now being an "API" that can be directly accessed via the STV, should it be needed. By auto-registering the API it implicitly becomes a REMOTE api with nothing that the end user has to do.

Phoenix works around this by auto-generating "API" stubs and then if you want to use them from the remote apis, you can EVAL them, (or use the phoenix auto-generated apis).

[Fuzzy]

I've obviously never had to maintain the numbers of plugins that you two have, but I'm curious which part of maintaining the manifests is the difficult part? How much of the difficulty is the requirement to make changes via the web form? How much easier would it be if it was as simply as altering a line or two in the SageTVPlugins.xml file on the GIT instead?

[Slugger]

I think it's tedium more than degree of difficulty. It's even more frustrating when everything you need already sits in an online repository that handles transitive dependency management, etc. (i.e. maven)

My biggest complaint about the plugin situation in Sage over the years is when I wrote something like SJQ, which depended on various Apache Commons jars, etc. So to deliver that plugin I first had to package up all those dependent jars as separate plugins. And these 3rd party plugins are nothing more than downloading the jar from maven, zipping it up, creating the xml manifest, finding another place on the internet to host this zip file and then submitting it for inclusion in the repo. If nothing else, why can't I just point to the jar file in maven as the download source? (This alone would be a massive improvement.) Then I discover that I'm using version n of commons-codec but someone else already delivered version (n - 1), but I need version n. So now I've got to beg that owner to update their plugin so that mine will work. Maybe they will, maybe they won't. Just as bad... later on I want to upgrade my plugin to use a newer version of commons-io but then I don't bother because that involves the tedium of zipping up a jar file, updating a manifest and resubmitting that plugin before I update my own plugin code, update that manifest and resubmit -- just as stuckless said, more times than not I just didn't bother.

With maven, all of these external jar files are sitting in a repository already. Even better, there are tools that handle transitive dependencies among these jars. So I want to use Apache's fluent-hc client... I tell maven that and it knows that I also need Apache http-client, etc, etc. Done. I want to use the latest and greatest version in my next release? Change the fluent-hc client version in my build/manifest/whatever and that's it. I don't need to go zipping up jar files and resubmitting those ahead of time.

Even better would be we store Sage plugins (at least the jars) as a maven repo itself. Tell the repo you want plugin-xyz then thru transitive properties it knows what other jars need to be pulled down with it. Not sure how feasible this actually is, but it just seems like we should be trying to leverage existing repositories (and all the features they bring) instead of having to rezip jar files on an ongoing basis. In the current system, I tend to punt on an update if I find that I need to repackage a bunch of 3rd party jar files as part of my planned update. In some cases, I just manually updated the jars on my own system, made my code change and dropped my new jar over the old one. Yes, I broke the plugin manager's state, but it saved me a tonne of work.

[stuckless]

Originally Posted by Fuzzy

I've obviously never had to maintain the numbers of plugins that you two have, but I'm curious which part of maintaining the manifests is the difficult part? How much of the difficulty is the requirement to make changes via the web form? How much easier would it be if it was as simply as altering a line or two in the SageTVPlugins.xml file on the GIT instead?

[sls@localhost tmp]$ grep '<Author>' SageTVPlugins.xml  | grep stuckless | wc -l
28
[sls@localhost tmp]$ grep '<Author>' SageTVPlugins.xml  | grep -i fuzzy | wc -l
10
[sls@localhost tmp]$ grep '<Author>' SageTVPlugins.xml  | grep -i tmiranda | wc -l
37
[sls@localhost tmp]$ grep '<Author>' SageTVPlugins.xml  | grep -i slugger | wc -l
60

You are not that far off... Slugger has 60, and I bet, 50+ are jar files I have 28 and I think I have 5 actual plugins, the rest are jar files.

But to answer you question, yeah, the web post is tedius... and I general skirt that process for updates using a script for but new plugins (jars)... it's building the manifest, creating the zip, and upload the zip "somewhere", then manually posting the web form, and waiting for the URL... and then of course if you have jar with transitive dependencies,then repeat for each jar, and then wait between posts for the email, or else they fail.

Hosting our own zipped jar files, when maven already hosts them, just seems wrong. And, Maven hosts the md5s for each jar as well, etc.

https://repo1.maven.org/maven2/org/a...mons-io/1.3.2/

I think that if i build a plugin, I need to specify the dependencies, but I don't think that I should be made to re-host all these dependencies, when they are already being hosts somewhere else.

And, other people are free to use a newer version of a jar without having to have me manually upgrade it for them, just because they need to use a newer api. (Something that I've had happen about 10 times now)

Leveraging maven central simplifies that process for everyone.

And it could be done in a backward compatible way. ie, the <Dependency> tag could be ammended like..

 <Dependency>
                <Plugin groupid="commons-io">commons-io</Plugin>
                <MinVersion>2.4</MinVersion>
 </Dependency>

or

 <Dependency>
                <Plugin>commons-io:commons-io:2.4</Plugin>
 </Dependency>

That's why this is a discussion... so we can sort it all out

[stuckless]

FYI on the break down of different Plugin Package Types...

[sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort |uniq
<PackageType>ChannelLogo</PackageType>
<PackageType>JAR</PackageType>
<PackageType>STVI</PackageType>
<PackageType>STV</PackageType>
<PackageType>System</PackageType>
[sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | wc -l
376
[sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep JAR | wc -l
162
[sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep STVI | wc -l
131
[sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep System | wc -l
67
[sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep ChannelLogo | wc -l
6
[sls@localhost tmp]$ grep 'PackageType' SageTVPlugins.xml | sed 's/\s//g' | sort | grep '>STV<' | wc -l
10

[jreichen]

I agree with creating plugin-specific directories. It would help keep the system organized and help the uninstaller clean them up, as well as help us create a class loader per plugin.

Getting rid of jar plugins is a good idea. However, I don't like the idea of plugins referencing the maven central repo or of having a shared jar directory for all plugins. Maven can be a headache and I think that should be limited to the developer's machine. I'd rather not introduce that on user's machines. The jars and other artifacts/resources should be built into the plugin's zip file and unzipped into the plugin-specific directory that's being proposed. This fits well with the plugin-specific directories.

Both of these ideas would help minimize the problems of different plugins using different versions of the same dependency. Plugins should be isolated from each other as much as they are from the core.

I like the idea of multiple plugin repositories. That would help developer and beta testing.

Scripted publishing would be nice. I don't know whether to go with hosting it on a web server or on GitHub. If it's on GitHub I'd suggest having it under a different repo than the core. That would help with managing access to the repos.

I don't think the MD5 problem will be an issue if everything is delivered in the plugin.zip file and that results in one entry in the plugin repository.

As far as scriptable plugins, any JVM language is already supported. Are you talking about letting developers deliver the script source, then having the core compile them when the plugin is installed? I like the idea. That would lower the burden on developers delivering scripts.

For API registration, do the sagex APIs "natively" support new APIs, or does the client have to put an eval into the URL? I think it would be great if the sagex APIs didn't need to be renegerated whenever the APIs change. A more dynamic implementation would make it a lot more flexible. Or maybe it already does this and I haven't kept up with it

[Fuzzy]

If the dependencies are already hosted elsewhere, you shouldn't have to host them yourself, just point the manifest to their otherwise hosted location. or am I missing something?

I'll be honest and say that I have absolutely no idea what Maven is - I was more trying to understand the insufficiency of the current system.

[jreichen]

It's not so much the hosting itself, it's more about dependency conflicts. I've worked on projects that use Maven and if dependencies of dependencies conflict it can be a real headache. I don't want somebody's Sage system to get that headache That's why I'm suggesting a directory and classloader per plugin.

[Slugger]

Originally Posted by Fuzzy

If the dependencies are already hosted elsewhere, you shouldn't have to host them yourself, just point the manifest to their otherwise hosted location. or am I missing something?

I'll be honest and say that I have absolutely no idea what Maven is - I was more trying to understand the insufficiency of the current system.

On maven, the jars are what's exposed. The Sage plugin requires a zip containing the jar and so that's why we have to download the jar, rezip it and host it somewhere else.

Originally Posted by jreichen

It's not so much the hosting itself, it's more about dependency conflicts. I've worked on projects that use Maven and if dependencies of dependencies conflict it can be a real headache. I don't want somebody's Sage system to get that headache That's why I'm suggesting a directory and classloader per plugin.

True, but that's up to the dev to sort out. In such cases (unrelated to Sage), I've had to exclude certain transitive dependencies in my gradle scripts. It sucks, but once I solved it, I add the exclusion to my build file and that's it. A classloader per plugin is advantageous but also introduces other issues. The least of which is plugins are going to duplicate commonly used jars. I suppose that's not a huge deal, space is cheap. A real issue might be that when you isolate plugins in their own classloader, all of a sudden plugins can't "talk" to each other since they're essentially being sandboxed, right? In this model, one plugin can't call code from another unless it also includes a copy of the other's jars, but when you do that you're not "talking" to the same instance of the plugin. (Think J2EE apps and jars in the lib of the war vs. jars in the container's lib/shared folder, etc.)

[stuckless]

Originally Posted by Fuzzy

If the dependencies are already hosted elsewhere, you shouldn't have to host them yourself, just point the manifest to their otherwise hosted location. or am I missing something?

I'll be honest and say that I have absolutely no idea what Maven is - I was more trying to understand the insufficiency of the current system.

In an open source system, IF google is not going to host all these for us, then each plugin developer will have to figure this out.

Today, we take jars, and wrap them in ZIP files.

  <Description>SageTV Dependency JAR Plugin for commons-io-1.4.jar - no need to download directly</Description>
    <Location>http://sourceforge.net/projects/sagetv-addons/files/3rd_party_libs/commons-io-2.4.zip/download</Location>

Originally Posted by jreichen

It's not so much the hosting itself, it's more about dependency conflicts. I've worked on projects that use Maven and if dependencies of dependencies conflict it can be a real headache. I don't want somebody's Sage system to get that headache That's why I'm suggesting a directory and classloader per plugin.

I think people are confusing a "Maven" repository with actually using Maven. I don't want to use Maven... I just want to use the well known maven repositories as a means of resolving JARs. If you even remotely have spent time in Java, then using a maven repository (independent of Maven) is old news.

ie, I don't want to re-host already pre-built jars somewhere else.

In terms of a maven repository, fundamentally it's nothing more than a http filesystem that has artifacts organized in a structured way, such that, tools like Mavan, Ant, Ivy, and a slew of other build tools can actually resolve artifacts.

Getting rid of jar plugins is a good idea. However, I don't like the idea of plugins referencing the maven central repo or of having a shared jar directory for all plugins. Maven can be a headache and I think that should be limited to the developer's machine. I'd rather not introduce that on user's machines. The jars and other artifacts/resources should be built into the plugin's zip file and unzipped into the plugin-specific directory that's being proposed. This fits well with the plugin-specific directories.

Yeah, the problem is a classloader per-plugin is that doing it yourself is ALOT of work. (I've done it, and can never come to osgi). So, then you are looking at OSGI which is overly complex, but does exactly what you are talking about.

I don't think the MD5 problem will be an issue if everything is delivered in the plugin.zip file and that results in one entry in the plugin repository.

I think today our MD5 is in the manifest, and it's for the .zip and not the .jar. When google code shut down and I had to start finding alternate places for my plugins, I ran into all kinds of issues with github for this I ended up using bintray.

Originally Posted by jreichen

As far as scriptable plugins, any JVM language is already supported. Are you talking about letting developers deliver the script source, then having the core compile them when the plugin is installed? I like the idea. That would lower the burden on developers delivering scripts.

I see this as something like...
<ImplementationClass>MyPlugin.py</ImplementationClass>
or
<ImplementationClass>MyPlugin.js</ImplementationClass>

Where the plugin would contina the .py/.js plugin implementation and by loaded like normal class. The first time loading, it would compile it.

For API registration, do the sagex APIs "natively" support new APIs, or does the client have to put an eval into the URL? I think it would be great if the sagex APIs didn't need to be renegerated whenever the APIs change. A more dynamic implementation would make it a lot more flexible. Or maybe it already does this and I haven't kept up with it

Yeah if the sagetv knows about an api you can call it using c=YouAPI&1=ARG1, etc, otherwise you need to use an Eval command.

[jreichen]

Originally Posted by Slugger

A classloader per plugin is advantageous but also introduces other issues. The least of which is plugins are going to duplicate commonly used jars. I suppose that's not a huge deal, space is cheap. A real issue might be that when you isolate plugins in their own classloader, all of a sudden plugins can't "talk" to each other since they're essentially being sandboxed, right? In this model, one plugin can't call code from another unless it also includes a copy of the other's jars, but when you do that you're not "talking" to the same instance of the plugin. (Think J2EE apps and jars in the lib of the war vs. jars in the container's lib/shared folder, etc.)

I was thinking about that, and the class loader could be implemented so it will look for jars in any of its plugin dependencies. Although I guess somewhere along the line you could still run into a versioning issue, but at least it wouldn't be with unrelated plugins.

[Narflex]

Originally Posted by tmiranda

Thanks for starting this thread. As somebody who has written a log of plugins I agree that some changes would be nice.

I would add to your list:

- Right now a "General" Plugin can't contain an STVi component. This means if you want to have a plugin that uses the functionality available as a General (Standard) plugin and you want it to modify the STV, you need to make two plugins and have one as a dependency of the other.

IIRC, there was a good reason for this. The whole server/client plugin installation thing got really complicated. And 'General' plugins weren't allowed to have STVI components because they would also run in the headless server context (I'd have to read the plugin documentation to recall this exactly). It got really ugly to determine what should be installed where when a user selected a plugin, and this decision helped with some of that complexity.

Regarding hosting plugins....many are hosted on download.sagetv.com. If you put your plugin on the semi-public FTP Server at download2.sagetv.com, then it automatically copies it over to download.sagetv.com for hosting after processing the manifest.

Having to put JARs in ZIP files does sound annoying. It shouldn't be all that hard to update the plugin system to accept JAR files as well (and then not unzip them if it sees a .jar extension). If i need to update the server code that verifies submissions, i can do that as well.

And I recall originally not requiring JAR files to be in separate library plugins (and I'm pretty sure it's still not required)...but then everyone started doing that to deal with JAR conflicts between plugins...which seemed like a decent solution to the problem.

I do understand a lot of the desire to change things here...as I haven't contributed any SageTV plugins that I can recall...so I don't see things from the other end. But definitely take a look through the current system first and get an understanding of how it functions internally; many changes may be a lot easier than you expect....or vice versa.

I'm not against changing the system, I just want to be sure it's better for both users and devs in the end if that's done....and not break something that's currently *working*...because I know for sure it was a huge PITA building the whole plugin architecture in SageTV. LOTS of ugly corner cases to deal with.

[jreichen]

Originally Posted by stuckless

I think people are confusing a "Maven" repository with actually using Maven. I don't want to use Maven... I just want to use the well known maven repositories as a means of resolving JARs. If you even remotely have spent time in Java, then using a maven repository (independent of Maven) is old news.

You're right I was. My experience has usually been using them together, but yes they don't have to be.

[stuckless]

Originally Posted by Narflex

Regarding hosting plugins....many are hosted on download.sagetv.com. If you put your plugin on the semi-public FTP Server at download2.sagetv.com, then it automatically copies it over to download.sagetv.com for hosting after processing the manifest.

I'm pretty sure I forgot about this But still, is google going to allow the open source sagetv to share fownload.sagetv.com? And will the opensource sagetv still utilize the SageTVPlugins.xml from sagetv.com or would it get it from somewhere else?? And who manage this. ie, I doubt any of us are going to splurge on a AWS node for hosting and processing plugin manifests

Originally Posted by Narflex

Having to put JARs in ZIP files does sound annoying. It shouldn't be all that hard to update the plugin system to accept JAR files as well (and then not unzip them if it sees a .jar extension). If i need to update the server code that verifies submissions, i can do that as well.

I think that would be a good intermediate step... but I still would like to Extend the <Dependendency> node to specifiy a jar that is not managed by the SageTV plugin manager directly. As you said, plugins don't have to treat jars are other plugins... you can simply bundle them internally, but we don't want people doing that either

Originally Posted by Narflex

I do understand a lot of the desire to change things here...as I haven't contributed any SageTV plugins that I can recall...so I don't see things from the other end. But definitely take a look through the current system first and get an understanding of how it functions internally; many changes may be a lot easier than you expect....or vice versa.

I'm not against changing the system, I just want to be sure it's better for both users and devs in the end if that's done....and not break something that's currently *working*...because I know for sure it was a huge PITA building the whole plugin architecture in SageTV. LOTS of ugly corner cases to deal with.

And that's why I wanted to have the discussion... I, or anyone, could just start making changes, but it would be nice to get some feedback before that happens.