Tika
  1. Tika
  2. TIKA-761

Provide version number by CLI argument -V

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: cli, general
    • Labels:
      None

      Description

      I'd like to get the Apache Tika version number through CLI argument -V or --version. The patch is trivial and basically finished. The only thing missing (because Java is not my native programming language) is the actual version number. Any hints where I can get that from?

      1. TIKA-761.diff
        2 kB
        Ingo Renner
      2. TIKA-761.diff
        2 kB
        Ingo Renner
      3. TIKA-761.diff
        2 kB
        Ingo Renner
      4. TIKA-761.diff
        4 kB
        Ingo Renner

        Activity

        Hide
        Nick Burch added a comment -

        The version is maintained in the pom, and Maven then puts that into the Manifest. I think the key in the tika-cli jar is "Bundle-Version", but hopefully one of the Maven gurus can confirm?

        Show
        Nick Burch added a comment - The version is maintained in the pom, and Maven then puts that into the Manifest. I think the key in the tika-cli jar is "Bundle-Version", but hopefully one of the Maven gurus can confirm?
        Hide
        Ingo Renner added a comment -

        just needs the version number in version()

        Show
        Ingo Renner added a comment - just needs the version number in version()
        Hide
        Ingo Renner added a comment -

        removed whitespace change

        Show
        Ingo Renner added a comment - removed whitespace change
        Hide
        Ingo Renner added a comment -

        @Nick, the version number in the pom was quite obvious, I just don't know how to access that in the app eventually.

        Show
        Ingo Renner added a comment - @Nick, the version number in the pom was quite obvious, I just don't know how to access that in the app eventually.
        Hide
        Ingo Renner added a comment -

        working patch.

        I added a properties file in the filtered resources path. This properties file is processed by maven when building and I can then read the version number from the properties.

        Show
        Ingo Renner added a comment - working patch. I added a properties file in the filtered resources path. This properties file is processed by maven when building and I can then read the version number from the properties.
        Hide
        Ingo Renner added a comment -

        BTW, how about using -v (lowercase) to get the version instead of using it for verbose as it is now?

        Show
        Ingo Renner added a comment - BTW, how about using -v (lowercase) to get the version instead of using it for verbose as it is now?
        Hide
        Nick Burch added a comment -

        I think -v for verbose is more common, so I wouldn't be in favour of changing it

        Show
        Nick Burch added a comment - I think -v for verbose is more common, so I wouldn't be in favour of changing it
        Hide
        Jukka Zitting added a comment -

        +1 Looks good.

        As a possible improvement, as Nick noted, you could read the version number from /META-INF/MANIFEST.MF or from /META-INF/maven/org.apache.tika/tika-app/pom.properties so we don't need to set up a custom properties file for this.

        Also, it would be cool if that information could be made available also through the Java API in tika-core. For example the toString() method of the Tika facade class could return something like "Apache Tika x.y", and tika-app --version would simply output that string.

        using -v (lowercase)

        -1 for backwards compatibility reasons.

        Show
        Jukka Zitting added a comment - +1 Looks good. As a possible improvement, as Nick noted, you could read the version number from /META-INF/MANIFEST.MF or from /META-INF/maven/org.apache.tika/tika-app/pom.properties so we don't need to set up a custom properties file for this. Also, it would be cool if that information could be made available also through the Java API in tika-core. For example the toString() method of the Tika facade class could return something like "Apache Tika x.y", and tika-app --version would simply output that string. using -v (lowercase) -1 for backwards compatibility reasons.
        Hide
        Ingo Renner added a comment - - edited

        +1 Looks good.

        thanks!

        As a possible improvement, as Nick noted, you could read the version number from /META-INF/MANIFEST.MF or from /META-INF/maven/org.apache.tika/tika-app/pom.properties so we don't need to set up a custom properties file for this.

        It seems - from what I read - these are only available after building the app, which would be too late( ? )

        Also, it would be cool if that information could be made available also through the Java API in tika-core. For example the toString() method of the Tika facade class could return something like "Apache Tika x.y", and tika-app --version would simply output that string.

        I'll give it a try.

        -1 for backwards compatibility reasons.

        fine with me, I just had the impression that -v was more common

        Show
        Ingo Renner added a comment - - edited +1 Looks good. thanks! As a possible improvement, as Nick noted, you could read the version number from /META-INF/MANIFEST.MF or from /META-INF/maven/org.apache.tika/tika-app/pom.properties so we don't need to set up a custom properties file for this. It seems - from what I read - these are only available after building the app, which would be too late( ? ) Also, it would be cool if that information could be made available also through the Java API in tika-core. For example the toString() method of the Tika facade class could return something like "Apache Tika x.y", and tika-app --version would simply output that string. I'll give it a try. -1 for backwards compatibility reasons. fine with me, I just had the impression that -v was more common
        Hide
        Jukka Zitting added a comment -

        It seems - from what I read - these are only available after building the app, which would be too late( ? )

        It's not too late. After all, you can only run the app after it has been built. We need the version information only at runtime, so it's not a problem if it's not available at compile-time.

        Show
        Jukka Zitting added a comment - It seems - from what I read - these are only available after building the app, which would be too late( ? ) It's not too late. After all, you can only run the app after it has been built. We need the version information only at runtime, so it's not a problem if it's not available at compile-time.
        Hide
        Ingo Renner added a comment -

        version.properties now in tika-core

        Show
        Ingo Renner added a comment - version.properties now in tika-core
        Hide
        Ingo Renner added a comment -

        Jukka, I hope this is what you meant with moving this to tika-core...

        However, I couldn't test the latest version of the patch since for some reason I'm now getting the following exception when executing tika-app. I haven't changed anything besides what's in the diff. Any ideas?

        Exception in thread "main" java.lang.NullPointerException
        at org.apache.tika.mime.MimeTypesFactory.create(MimeTypesFactory.java:81)
        at org.apache.tika.mime.MimeTypesFactory.create(MimeTypesFactory.java:135)
        at org.apache.tika.mime.MimeTypes.getDefaultMimeTypes(MimeTypes.java:573)
        at org.apache.tika.detect.DefaultDetector.<init>(DefaultDetector.java:63)
        at org.apache.tika.cli.TikaCLI.<init>(TikaCLI.java:295)
        at org.apache.tika.cli.TikaCLI.main(TikaCLI.java:96)

        Show
        Ingo Renner added a comment - Jukka, I hope this is what you meant with moving this to tika-core... However, I couldn't test the latest version of the patch since for some reason I'm now getting the following exception when executing tika-app. I haven't changed anything besides what's in the diff. Any ideas? Exception in thread "main" java.lang.NullPointerException at org.apache.tika.mime.MimeTypesFactory.create(MimeTypesFactory.java:81) at org.apache.tika.mime.MimeTypesFactory.create(MimeTypesFactory.java:135) at org.apache.tika.mime.MimeTypes.getDefaultMimeTypes(MimeTypes.java:573) at org.apache.tika.detect.DefaultDetector.<init>(DefaultDetector.java:63) at org.apache.tika.cli.TikaCLI.<init>(TikaCLI.java:295) at org.apache.tika.cli.TikaCLI.main(TikaCLI.java:96)
        Hide
        Ingo Renner added a comment -

        Got the NPE resolved, it was caused by the changes to the pom. Since adding explicit resource directives Maven didn't copy tika-mimetypes.xml into the jar anymore. Fixed patch coming up...

        Show
        Ingo Renner added a comment - Got the NPE resolved, it was caused by the changes to the pom. Since adding explicit resource directives Maven didn't copy tika-mimetypes.xml into the jar anymore. Fixed patch coming up...
        Hide
        Ingo Renner added a comment -

        Hi Nick and Jukka, some update on the META-INF approach:

        The path for the properties file would be
        /META-INF/maven/org.apache.tika/tika-core/pom.properties

        I tried
        String pomPropertiesFile = "/META-INF/maven/"
        + this.getClass().getPackage().getName()
        + "/tika-core/pom.properties";
        InputStream pomIs = Tika.class.getResourceAsStream(pomPropertiesFile);

        Problem is that getResourceAsStream replaces dots in the path with slashes except for the last one. So the path becomes something like /META-INF/maven/org/apache/tika/tika-core/pom.properties leading to an NPE when trying to load the properties from pomIs. ... Leaving us (me?) w/o a way to get to this properties file...

        Any ideas?

        Show
        Ingo Renner added a comment - Hi Nick and Jukka, some update on the META-INF approach: The path for the properties file would be /META-INF/maven/org.apache.tika/tika-core/pom.properties I tried String pomPropertiesFile = "/META-INF/maven/" + this.getClass().getPackage().getName() + "/tika-core/pom.properties"; InputStream pomIs = Tika.class.getResourceAsStream(pomPropertiesFile); Problem is that getResourceAsStream replaces dots in the path with slashes except for the last one. So the path becomes something like /META-INF/maven/org/apache/tika/tika-core/pom.properties leading to an NPE when trying to load the properties from pomIs. ... Leaving us (me?) w/o a way to get to this properties file... Any ideas?
        Hide
        Jukka Zitting added a comment - - edited

        I'd simply hardcode the properties file path as /META-INF/maven/org.apache.tika/tika-core/pom.properties. It's not going to change any time soon.

        Show
        Jukka Zitting added a comment - - edited I'd simply hardcode the properties file path as /META-INF/maven/org.apache.tika/tika-core/pom.properties . It's not going to change any time soon.
        Hide
        Ingo Renner added a comment -

        sure, but the dots will still be replaced with slashes by getResourceAsStream(), so it won't matter really (except for saving the getPackage() call)...

        Show
        Ingo Renner added a comment - sure, but the dots will still be replaced with slashes by getResourceAsStream(), so it won't matter really (except for saving the getPackage() call)...
        Hide
        Jukka Zitting added a comment -

        the dots will still be replaced with slashes

        Only if the path is relative. If the path starts with a slash, like in /META-INF/..., no dot replacement will occur.

        Show
        Jukka Zitting added a comment - the dots will still be replaced with slashes Only if the path is relative. If the path starts with a slash, like in /META-INF/... , no dot replacement will occur.
        Hide
        Ingo Renner added a comment - - edited

        oh wow, indeed works. ... false alarm, still not working.

        Show
        Ingo Renner added a comment - - edited oh wow, indeed works . ... false alarm, still not working.
        Hide
        Jukka Zitting added a comment -

        See revision 1188803 for a slightly modified version of your latest patch that seems to do the trick.

        Show
        Jukka Zitting added a comment - See revision 1188803 for a slightly modified version of your latest patch that seems to do the trick.
        Hide
        Ingo Renner added a comment -

        hmm, can't get it to work for me, stream is null.
        What did you do to get it working on your end?

        In case it matters, I'm on OS X Lion:
        java -version
        java version "1.6.0_26"
        Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
        Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)

        Show
        Ingo Renner added a comment - hmm, can't get it to work for me, stream is null. What did you do to get it working on your end? In case it matters, I'm on OS X Lion: java -version java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)
        Hide
        Jukka Zitting added a comment -

        In revision 1190416 I added a missing piece of POM configuration for copying the /META-INF/maven resources from tika-core also to tika-app.

        Show
        Jukka Zitting added a comment - In revision 1190416 I added a missing piece of POM configuration for copying the /META-INF/maven resources from tika-core also to tika-app.
        Hide
        Ingo Renner added a comment -

        confirmed, working now. Thanks!

        Show
        Ingo Renner added a comment - confirmed, working now. Thanks!

          People

          • Assignee:
            Jukka Zitting
            Reporter:
            Ingo Renner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development