Automatic removal of bad Lucene JAR file

[Fuzzy]

Luckily, the lucene issue isn't as significant on the linux side, as there are very few potential upgraders from v7 linux to v9 linux.

[EnterNoEscape]

Originally Posted by stuckless

That will work. Java does search the classpath in order, which is why I said it would a nice future enhancement to separate the jars and put the sage system ones in a separate folder. But yeah, we could add lucene (and the other sagetv core jars) explicitly to the start of the classpath. Also if we do this change, I'd like to see "." removed from the classpath... I'm not sure why it gets added, but, it caused me some grief some months ago

I assume you are still volunteering to do this

So we have discovered that at least one plugin broke because of this change. I don't think it will be a big deal for Tom to address this, but it makes me wonder if anything else is now broken.

https://forums.sagetv.com/forums/sho...&postcount=531

I'm not arguing to change it back, but there might have been a reason why it was done that way before that we will discover eventually.

[stuckless]

Originally Posted by EnterNoEscape

So we have discovered that at least one plugin broke because of this change. I don't think it will be a big deal for Tom to address this, but it makes me wonder if anything else is now broken.

https://forums.sagetv.com/forums/sho...&postcount=531

I'm not arguing to change it back, but there might have been a reason why it was done that way before that we will discover eventually.

I'd prefer to leave it out... since adding . to the classpath (especially in sagetv can really slow things down, especially for things that search the classpath).

I also encountered an endless loop condition when testing Tomcat as an embedded server, because of the "." in the classpath.

In general practice I don't think that adding "." is a good design... I think I'd rather find/fix the issues as they come up. If we get to a critical mass where more things are not working than working... I'd likely change my mind

[tmiranda]

Originally Posted by EnterNoEscape

So we have discovered that at least one plugin broke because of this change. I don't think it will be a big deal for Tom to address this, but it makes me wonder if anything else is now broken.

https://forums.sagetv.com/forums/sho...&postcount=531

I'm not arguing to change it back, but there might have been a reason why it was done that way before that we will discover eventually.

This will break several of my plugins.

[EnterNoEscape]

Originally Posted by stuckless

I'd prefer to leave it out... since adding . to the classpath (especially in sagetv can really slow things down, especially for things that search the classpath).

I also encountered an endless loop condition when testing Tomcat as an embedded server, because of the "." in the classpath.

In general practice I don't think that adding "." is a good design... I think I'd rather find/fix the issues as they come up. If we get to a critical mass where more things are not working than working... I'd likely change my mind

I find it odd that the JVM doesn't just expand the classpath to the absolute path of the files. In my mind if you're in the directory /opt/sagetv/server, ./folder, folder and /opt/sagetv/server/folder resolve to the same thing. I find it odd that this somehow influences where the JAR thinks it current path is.

[stuckless]

Originally Posted by EnterNoEscape

I find it odd that the JVM doesn't just expand the classpath to the absolute path of the files. In my mind if you're in the directory /opt/sagetv/server, ./folder, folder and /opt/sagetv/server/folder resolve to the same thing. I find it odd that this somehow influences where the JAR thinks it current path is.

Not sure I understand. The "jar" doesn't have a conscept of current working directory, but, it may if you add "." to it. Not sure if my response in the other thread covered it not, but basically. getResource() searches each entry in the classpath, independently, sort of treating each entry as a separate entity (as it should).

[EnterNoEscape]

Originally Posted by stuckless

Not sure I understand. The "jar" doesn't have a conscept of current working directory, but, it may if you add "." to it. Not sure if my response in the other thread covered it not, but basically. getResource() searches each entry in the classpath, independently, sort of treating each entry as a separate entity (as it should).

It might just be a small misunderstanding on my part about how the classpath works.

[sflamm]

So the questions is... since tmiranda is the author of several crazy valuable plugins like commercial detector... do these now work or are broken? (would like to know before I update...

[tmiranda]

Originally Posted by sflamm

So the questions is... since tmiranda is the author of several crazy valuable plugins like commercial detector... do these now work or are broken? (would like to know before I update...

CommercialDetector works fine.
YouTube is broken but I have the fix and will update the plugin tomorrow.
If anything else breaks I'll fix it ASAP.

[sflamm]

as always - thanks for the quick response and contributions!