Re: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
Hi Nick, On Fri, Jan 30, 2015 at 3:22 AM, dev-digest-h...@tika.apache.org wrote: The problem is that Tika has three kinds of users: You forgot about people who use and love Tika on their chicken. Mmm yum yum nom nom. I am starving. Tika on my chicken satay nom nom nom. People in the first two categories can move to a newer JVM fairly easily, if they aren't already on one. Those in the latter category find it a huge amount of effort to upgrade their JVM, sometimes almost impossible to do. If we move to a newer JVM, we'll loose those people Seriously though, I don't think we do. I am not convinced that projects seriously consider pegging everything at Java 1.6 to avoid loosing an unknown number of users of large anonymous frameworks unknown to the community developing the tool. If people cannot upgrade a JVM on pools of machines with a rolling upgrade just like they do with everything else then there are serious problems in that particular organization that need to be tackled and addressed. IMHO this is not something we should be particularly concerned with. By users on the lists, I'd suspect most are in categories 1 and 2. By overall users, it's quite possible that category 3 wins, so we do need to take care of their interests too! What are their interests though? As an example, Alfresco only moved to requiring Java 7 with Alfresco 4.2, 4.1 (still quite widely installed, and very much still supported) has a minimum of Java 6. If we move to Java 7, that'll mean that if there's an Alfresco bug traced back to Tika, they'll have to backport it into a private branch of Tika that's 1.6 compatible. It'll also mean they'll be less inclined to move to a newer Tika, as it'd mean more support hassle if some versions of Alfresco are on stock Tika $latest, and others are on a private older branch. Alfresco are generally quite good as vendors go, so expect many other large systems bundling Tika to be much much worse... My opinion is that as an open source project we should not be deterred from progressing the development of volunteer effort due to things like you have described above. If infrastructure level vendors have issues with their development cycle and they need to address that. Please note that the Oracle announcement I cited dates back to Aug, 2012. This is not recent news. If commercial companies can't schedule an upgrade from Java 1.6-1.7 over a period of some 3 years then there is something wrong. My 92 year old grandmother could learn to do a rolling upgrade of Java in 3 years. (I cannot verify this, my grandmother ay even be dead as I type this, I've not seen her in around 3 or so years thank god.) I'm not saying don't upgrade, just trying to make sure everyone's aware of what we loose + what problems we cause for our users, so it can be correctly weighed up against the benefits! Benefits are that we continue with development alongside countless other projects who are moving with the times. Con's are that some commercial entities (and non-commercial entites) find this a PITA for a while until they start planning for rolling upgrades to their products 3 years after the end of life support was announced. It is called end of life for a reason... namely because it is the end of it's life. :) Oh, and don't forget that Java 6 is still supported for another 23 months, for those willing to pay (and I believe there are many who do!) I think it would be to our advantage to make an upgrade to Java 1.7. If it does not work for 1.8, then we can push a 1.8.1 which reverts the change. No harm done. The release announcement needs to state that you should now use = Java 1.7. We can verify this with our Jenkins builds. Thanks Nikc, looking forward to catching you up for a Whisky at ApacheCon. Lewis
Re: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
Hi Konstantin, On Fri, Jan 30, 2015 at 3:22 AM, dev-digest-h...@tika.apache.org wrote: Are there Apache projects that depend on Tika which want to be compatible with 1.6? This is an extremely difficult question to even consider. I value my sleep so I am not going to try and do this research :) At least we should ask Solr folks about that, I think. I don't! Why would we ask Solr? They consume Tika the same as anyone else. Many projects (Solr 4.X included IIRC) e.g. Cassandra 2.X just jumped to Java 1.7 meing that users need to upgrade their systems. 1.6 is an old version of Java. There was talk about early release Java 9 JDK's for build slaves not long ago in Oracles offices in Dublin. Lewis
Re: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
On Thu, 29 Jan 2015, Lewis John Mcgibbney wrote: Do we want to move towards dropping support for Java 1.6? Oracle made an announcement some time ago so this is not exactly new news https://blogs.oracle.com/henrik/entry/java_6_eol_h_h The problem is that Tika has three kinds of users: * Those using the standalone tools * Those adding Tika into a smallish app they're developing * Those using Tika as part of a large system / framework People in the first two categories can move to a newer JVM fairly easily, if they aren't already on one. Those in the latter category find it a huge amount of effort to upgrade their JVM, sometimes almost impossible to do. If we move to a newer JVM, we'll loose those people By users on the lists, I'd suspect most are in categories 1 and 2. By overall users, it's quite possible that category 3 wins, so we do need to take care of their interests too! As an example, Alfresco only moved to requiring Java 7 with Alfresco 4.2, 4.1 (still quite widely installed, and very much still supported) has a minimum of Java 6. If we move to Java 7, that'll mean that if there's an Alfresco bug traced back to Tika, they'll have to backport it into a private branch of Tika that's 1.6 compatible. It'll also mean they'll be less inclined to move to a newer Tika, as it'd mean more support hassle if some versions of Alfresco are on stock Tika $latest, and others are on a private older branch. Alfresco are generally quite good as vendors go, so expect many other large systems bundling Tika to be much much worse... I'm not saying don't upgrade, just trying to make sure everyone's aware of what we loose + what problems we cause for our users, so it can be correctly weighed up against the benefits! Oh, and don't forget that Java 6 is still supported for another 23 months, for those willing to pay (and I believe there are many who do!) Nick
Re: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
Hi, folks. +1 for moving to 1.7. Are there Apache projects that depend on Tika which want to be compatible with 1.6? At least we should ask Solr folks about that, I think. -- Best regards, Konstantin Gribov
Re: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
Hi there, +1 for dropping. On 30 Jan 2015 05:05, Tyler Palsulich tpalsul...@gmail.com wrote: +1 Tyler On Jan 29, 2015 9:52 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: +1 move to 1.7 Sent from my iPhone On Jan 29, 2015, at 5:04 PM, Allison, Timothy B. talli...@mitre.org wrote: +1 to dropping 1.6...let's move to 1.8 and beyond! :) -Original Message- From: Lewis John Mcgibbney [mailto:lewis.mcgibb...@gmail.com] Sent: Thursday, January 29, 2015 6:51 PM To: dev@tika.apache.org Subject: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6 Hi Folks, Having committed TIKA-1423 it has become apparent to me that the libraries being pulled as dependencies are not compatible with JDK 1.6 as indicated with our Jenkins 1.6 build. Do we want to move towards dropping support for Java 1.6? Oracle made an announcement some time ago so this is not exactly new news https://blogs.oracle.com/henrik/entry/java_6_eol_h_h [ERROR] Failed to execute goal de.thetaphi:forbiddenapis:1.7:check (default) on project tika-parsers: Check for forbidden API calls failed: java.lang.ClassNotFoundException: Class 'java.lang.AutoCloseable' not found on classpath - [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException[ERROR] [ERROR] After correcting the problems, you can resume the build with the command[ERROR] mvn goals -rf :tika-parsers -- *Lewis*
Re: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
We can try to isolate module which depends on 1.7. Something like creating tika-parsers-ext which needs 1.7 when all other *library* will use 1.6. Non-library tika parts (like tika-app, tika-server) can easyly use 1.7 to run, it doesn't affect 3rd user group (by Nick's classification). Also, if only check/build tools (like forbiddenapis) need 1.7 then we should try to resolve issue there. OTOH such breaking change can be done in major release (on switching to 2.0) since it can break something anyway. -- Best regards, Konstantin Gribov Fri Jan 30 2015 at 12:33:30, Nick Burch apa...@gagravarr.org: On Thu, 29 Jan 2015, Lewis John Mcgibbney wrote: Do we want to move towards dropping support for Java 1.6? Oracle made an announcement some time ago so this is not exactly new news https://blogs.oracle.com/henrik/entry/java_6_eol_h_h The problem is that Tika has three kinds of users: * Those using the standalone tools * Those adding Tika into a smallish app they're developing * Those using Tika as part of a large system / framework People in the first two categories can move to a newer JVM fairly easily, if they aren't already on one. Those in the latter category find it a huge amount of effort to upgrade their JVM, sometimes almost impossible to do. If we move to a newer JVM, we'll loose those people By users on the lists, I'd suspect most are in categories 1 and 2. By overall users, it's quite possible that category 3 wins, so we do need to take care of their interests too! As an example, Alfresco only moved to requiring Java 7 with Alfresco 4.2, 4.1 (still quite widely installed, and very much still supported) has a minimum of Java 6. If we move to Java 7, that'll mean that if there's an Alfresco bug traced back to Tika, they'll have to backport it into a private branch of Tika that's 1.6 compatible. It'll also mean they'll be less inclined to move to a newer Tika, as it'd mean more support hassle if some versions of Alfresco are on stock Tika $latest, and others are on a private older branch. Alfresco are generally quite good as vendors go, so expect many other large systems bundling Tika to be much much worse... I'm not saying don't upgrade, just trying to make sure everyone's aware of what we loose + what problems we cause for our users, so it can be correctly weighed up against the benefits! Oh, and don't forget that Java 6 is still supported for another 23 months, for those willing to pay (and I believe there are many who do!) Nick
TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
Hi Folks, Having committed TIKA-1423 it has become apparent to me that the libraries being pulled as dependencies are not compatible with JDK 1.6 as indicated with our Jenkins 1.6 build. Do we want to move towards dropping support for Java 1.6? Oracle made an announcement some time ago so this is not exactly new news https://blogs.oracle.com/henrik/entry/java_6_eol_h_h [ERROR] Failed to execute goal de.thetaphi:forbiddenapis:1.7:check (default) on project tika-parsers: Check for forbidden API calls failed: java.lang.ClassNotFoundException: Class 'java.lang.AutoCloseable' not found on classpath - [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException[ERROR] [ERROR] After correcting the problems, you can resume the build with the command[ERROR] mvn goals -rf :tika-parsers -- *Lewis*
Re: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
+1 move to 1.7 Sent from my iPhone On Jan 29, 2015, at 5:04 PM, Allison, Timothy B. talli...@mitre.org wrote: +1 to dropping 1.6...let's move to 1.8 and beyond! :) -Original Message- From: Lewis John Mcgibbney [mailto:lewis.mcgibb...@gmail.com] Sent: Thursday, January 29, 2015 6:51 PM To: dev@tika.apache.org Subject: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6 Hi Folks, Having committed TIKA-1423 it has become apparent to me that the libraries being pulled as dependencies are not compatible with JDK 1.6 as indicated with our Jenkins 1.6 build. Do we want to move towards dropping support for Java 1.6? Oracle made an announcement some time ago so this is not exactly new news https://blogs.oracle.com/henrik/entry/java_6_eol_h_h [ERROR] Failed to execute goal de.thetaphi:forbiddenapis:1.7:check (default) on project tika-parsers: Check for forbidden API calls failed: java.lang.ClassNotFoundException: Class 'java.lang.AutoCloseable' not found on classpath - [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException[ERROR] [ERROR] After correcting the problems, you can resume the build with the command[ERROR] mvn goals -rf :tika-parsers -- *Lewis*
Re: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
+1 Tyler On Jan 29, 2015 9:52 PM, Mattmann, Chris A (3980) chris.a.mattm...@jpl.nasa.gov wrote: +1 move to 1.7 Sent from my iPhone On Jan 29, 2015, at 5:04 PM, Allison, Timothy B. talli...@mitre.org wrote: +1 to dropping 1.6...let's move to 1.8 and beyond! :) -Original Message- From: Lewis John Mcgibbney [mailto:lewis.mcgibb...@gmail.com] Sent: Thursday, January 29, 2015 6:51 PM To: dev@tika.apache.org Subject: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6 Hi Folks, Having committed TIKA-1423 it has become apparent to me that the libraries being pulled as dependencies are not compatible with JDK 1.6 as indicated with our Jenkins 1.6 build. Do we want to move towards dropping support for Java 1.6? Oracle made an announcement some time ago so this is not exactly new news https://blogs.oracle.com/henrik/entry/java_6_eol_h_h [ERROR] Failed to execute goal de.thetaphi:forbiddenapis:1.7:check (default) on project tika-parsers: Check for forbidden API calls failed: java.lang.ClassNotFoundException: Class 'java.lang.AutoCloseable' not found on classpath - [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException[ERROR] [ERROR] After correcting the problems, you can resume the build with the command[ERROR] mvn goals -rf :tika-parsers -- *Lewis*
RE: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6
+1 to dropping 1.6...let's move to 1.8 and beyond! :) -Original Message- From: Lewis John Mcgibbney [mailto:lewis.mcgibb...@gmail.com] Sent: Thursday, January 29, 2015 6:51 PM To: dev@tika.apache.org Subject: TIKA-1423 Build a parser to extract data from GRIB formats not good with Java 6 Hi Folks, Having committed TIKA-1423 it has become apparent to me that the libraries being pulled as dependencies are not compatible with JDK 1.6 as indicated with our Jenkins 1.6 build. Do we want to move towards dropping support for Java 1.6? Oracle made an announcement some time ago so this is not exactly new news https://blogs.oracle.com/henrik/entry/java_6_eol_h_h [ERROR] Failed to execute goal de.thetaphi:forbiddenapis:1.7:check (default) on project tika-parsers: Check for forbidden API calls failed: java.lang.ClassNotFoundException: Class 'java.lang.AutoCloseable' not found on classpath - [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException[ERROR] [ERROR] After correcting the problems, you can resume the build with the command[ERROR] mvn goals -rf :tika-parsers -- *Lewis*
