These are minor nitpicks but they address significant questions about the scope of core.
On Fri, Sep 19, 2014 at 1:19 AM, cowwoc <cowwoc@xxxxxxxxxxxxxxxx> wrote:
I am beginning to feel like people are putting words in my mouth :)
I agree with most of what you said. I will only comment on the differences:
There is nothing special in java, that's just another language like perl, python and tcl. I don't see any reason to treat that differently.
I don't disagree per-se. I think bundling the JRE would help users, but it's a tiny problem compared to needing to build pl/java from source. If we can fix the latter, the former is a smaller issue. Sidenote: when I talk about "bundling" the JRE I simply mean adding an option in the installer to download and unpack it on behalf of the user.
Does core even maintain installers? If so, which ones?
I don't disagree with the goal of making the software easy to install, but asking the core team to maintain it so it will end up in Stack Builder is the wrong approach.
If there is a programmer who cannot install jvm/jdk on its own (which is a couple of clicks on windows and linux) then I'm sure that writing stored procerures in java will be even too difficult.
Installing a public JVM is easy. Binding it to pl/java is not. By bundling a private JRE we control the default installation path and can therefore pre-configure pl/java to look for it in that location.
On 19/09/2014 3:18 AM, Szymon Guz wrote:
You only forgot about the guava version. What if I need another version?
I never meant to imply we would bundle Java libraries with pl/java. The only thing we should bundle is the private JRE. Users will be responsible for adding libraries to the classpath in the same way they add their triggers.
One more question is who is "we?" And are the same considerations on Debian and RHEL as on Windows? And if not, then is the best approach here to work first with packagers here? What about source compilations?
To be honest I suspect that the following would be a more productive approach:
1. The pl/java project needs to ensure the software is easy to install. Nobody else is going to be able to take that over.
2. Evangelism on the capabilities of the project including in migrations from Oracle etc. needs to be given a priority. Community building is good.
3. Work with packagers to get the software easily installable on multiple platforms. Work with the maintainers of the Windows installer to include that. Work with packagers on Debian, RHEL, Fedora, etc. for that.
I think that process will get you everything and more that handing it off to core would.
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.
