Lucene - Core
  1. Lucene - Core
  2. LUCENE-908

MANIFEST.MF cleanup (main jar and luci customizations)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3
    • Component/s: general/build
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      there are several problems with the MANIFEST.MF file used in the core jar, and some inconsistencies in th luci jar:

      Lucli's build.xml has an own "jar" target and does not use the jar target from common-build.xml. The result
      is that the MANIFEST.MF file is not consistent and the META-INF dir does not contain LICENSE.TXT and NOTICE.TXT.

      Is there a reason why lucli behaves different in this regard? If not I think we should fix this.

      1. lucene-908.patch
        11 kB
        Michael Busch
      2. LUCENE-908.patch
        5 kB
        Hoss Man
      3. lucene-908-new.patch
        15 kB
        Michael Busch

        Activity

        Michael Busch created issue -
        Hide
        Steven Parkes added a comment -

        I'm pretty sure it's to get the stuff that's in the MANIFEST.MF in there: the Main-Class header, in particular. With this, you can say java -jar jar w/o having to specify the main class.

        Probably simplest just to also add the necessary files/lines manually? It's not DRY with the code common-build.xml, but it's simple for an uncommon case.

        Show
        Steven Parkes added a comment - I'm pretty sure it's to get the stuff that's in the MANIFEST.MF in there: the Main-Class header, in particular. With this, you can say java -jar jar w/o having to specify the main class. Probably simplest just to also add the necessary files/lines manually? It's not DRY with the code common-build.xml, but it's simple for an uncommon case.
        Hide
        Hoss Man added a comment -

        the existing jar logic in common-build.xml could be refacotred into a macro with a a nested tag option so that contribs could add additional items, that would probably be the cleanest way to support MANIFEST.MF add ons.

        on a related subject, when i was setting up the solr MANIFEST.MF i discovered lots of things are "wrong" about the way Lucene's MANIFEST file is built (aparently i never raised them in lucene-java, or if i did we never did anythng about them), here are the comments from Solr's build.xml that we may also want to fix...

        http://svn.apache.org/viewvc/lucene/solr/trunk/build.xml
        <!--
        http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#JAR%20Manifest
        http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.html
        http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Package.html
        http://java.sun.com/j2se/1.5.0/docs/api/java/util/jar/package-summary.html
        http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html
        -->
        <!-- Don't set 'Manifest-Version' it identifies the version of the
        manifest file format, and should allways be 1.0 (the default)

        Don't set 'Created-by' attribute, it's purpose is
        to identify the version of java used to build the jar,
        which ant will do by default.

        Ant will happily override these with bogus strings if you
        tell it to, so don't.

        NOTE: we don't use section info because all of our manifest data
        applies to the entire jar/war ... no package specific info.
        -->
        <!-- spec version must match "digit+

        {.digit+}

        *" -->
        <!-- impl version can be any string -->

        Show
        Hoss Man added a comment - the existing jar logic in common-build.xml could be refacotred into a macro with a a nested tag option so that contribs could add additional items, that would probably be the cleanest way to support MANIFEST.MF add ons. on a related subject, when i was setting up the solr MANIFEST.MF i discovered lots of things are "wrong" about the way Lucene's MANIFEST file is built (aparently i never raised them in lucene-java, or if i did we never did anythng about them), here are the comments from Solr's build.xml that we may also want to fix... http://svn.apache.org/viewvc/lucene/solr/trunk/build.xml <!-- http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#JAR%20Manifest http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.html http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Package.html http://java.sun.com/j2se/1.5.0/docs/api/java/util/jar/package-summary.html http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html --> <!-- Don't set 'Manifest-Version' it identifies the version of the manifest file format, and should allways be 1.0 (the default) Don't set 'Created-by' attribute, it's purpose is to identify the version of java used to build the jar, which ant will do by default. Ant will happily override these with bogus strings if you tell it to, so don't. NOTE: we don't use section info because all of our manifest data applies to the entire jar/war ... no package specific info. --> <!-- spec version must match "digit+ {.digit+} *" --> <!-- impl version can be any string -->
        Hoss Man made changes -
        Field Original Value New Value
        Summary Lucli doesn't include standard MANIFEST.MF MANIFEST.MF cleanup (main jar and luci customizations)
        Description Is there a particular reason why lucli has it's own MANIFEST.MF file? Lucli's build.xml
        has an own "jar" target and does not use the jar target from common-build.xml. The result
        is that the MANIFEST.MF file does not contain infos like "Created-By Apache Lucene Java",
        neither does META-INF contain LICENSE.TXT and NOTICE.TXT.

        Is there a reason why lucli behaves different in this regard? If not I think we should fix this.
        there are several problems with the MANIFEST.MF file used in the core jar, and some inconsistencies in th luci jar:

        Lucli's build.xml has an own "jar" target and does not use the jar target from common-build.xml. The result
        is that the MANIFEST.MF file is not consistent and the META-INF dir does not contain LICENSE.TXT and NOTICE.TXT.

        Is there a reason why lucli behaves different in this regard? If not I think we should fix this.
        Hide
        Michael Busch added a comment -

        Hi Hoss,

        I think this makes sense. It would be great if you could provide a patch here?

        Show
        Michael Busch added a comment - Hi Hoss, I think this makes sense. It would be great if you could provide a patch here?
        Hide
        Hoss Man added a comment -

        quick pass at adopting some of the stuff i learned doing the Solr MANIFEST.MF ... i haven't tested it extensively (Michael i'm hoping you can take the ball and run with it, i've got about a million other things going on at the moment)

        note: it was a while ago when i looked into all of this MANIFEST stuff and i'm not sure i fully understood it then, let alone now.

        patch moves jaring into a new macro (jarify) ... contribs can override the "jar-core" target to call jarify and override some options as well as add new <attributes> to appear in the manifest file.

        manifest now includes a lot more information then it did before.

        things this doesn't address...

        • manifest file in demo war file
        • manifest file in any of gdata's jars/war (it doesn't use the contrib-build.xml either)
        • spec version must match "digit+ {.digit+}

          *" ... this is true for our official releases, but broken in our nightlies.

        • need to svn remove the existing luci MANIFEST file
        • should luci's "Class-Path" refer to the full name of the lucene core jar?
        Show
        Hoss Man added a comment - quick pass at adopting some of the stuff i learned doing the Solr MANIFEST.MF ... i haven't tested it extensively (Michael i'm hoping you can take the ball and run with it, i've got about a million other things going on at the moment) note: it was a while ago when i looked into all of this MANIFEST stuff and i'm not sure i fully understood it then, let alone now. patch moves jaring into a new macro (jarify) ... contribs can override the "jar-core" target to call jarify and override some options as well as add new <attributes> to appear in the manifest file. manifest now includes a lot more information then it did before. things this doesn't address... manifest file in demo war file manifest file in any of gdata's jars/war (it doesn't use the contrib-build.xml either) spec version must match "digit+ {.digit+} *" ... this is true for our official releases, but broken in our nightlies. need to svn remove the existing luci MANIFEST file should luci's "Class-Path" refer to the full name of the lucene core jar?
        Hoss Man made changes -
        Attachment LUCENE-908.patch [ 12359014 ]
        Hide
        Michael Busch added a comment -

        > Michael i'm hoping you can take the ball and run with it,

        Thanks for the pass, Hoss, I'm already running...

        Show
        Michael Busch added a comment - > Michael i'm hoping you can take the ball and run with it, Thanks for the pass, Hoss, I'm already running...
        Hide
        Michael Busch added a comment -

        > * manifest file in any of gdata's jars/war (it doesn't use the contrib-build.xml either)
        > * should luci's "Class-Path" refer to the full name of the lucene core jar?

        I would like to ask the contrib owners to take care of these issues.

        > * spec version must match "digit+

        {.digit+}

        *" ... this is true for our official releases,
        > but broken in our nightlies.

        I will leave this for now as this patch doesn't change the spec version.

        > * need to svn remove the existing luci MANIFEST file
        > * manifest file in demo war file

        Will take care...

        Show
        Michael Busch added a comment - > * manifest file in any of gdata's jars/war (it doesn't use the contrib-build.xml either) > * should luci's "Class-Path" refer to the full name of the lucene core jar? I would like to ask the contrib owners to take care of these issues. > * spec version must match "digit+ {.digit+} *" ... this is true for our official releases, > but broken in our nightlies. I will leave this for now as this patch doesn't change the spec version. > * need to svn remove the existing luci MANIFEST file > * manifest file in demo war file Will take care...
        Hide
        Michael Busch added a comment -

        In addition to Hoss' great patch this one:

        • changes the MANIFEST file in the demo jar and war in a consistent way
        • adds a patternset via refid to the metainf type of jarify. This can
          be used by contrib modules to add additional files to the META-INF dir.
          I use it to add SNOWBALL-LICENSE.txt to META-INF of the snowball jar.

        I'm planning to commit this soon.

        Show
        Michael Busch added a comment - In addition to Hoss' great patch this one: changes the MANIFEST file in the demo jar and war in a consistent way adds a patternset via refid to the metainf type of jarify. This can be used by contrib modules to add additional files to the META-INF dir. I use it to add SNOWBALL-LICENSE.txt to META-INF of the snowball jar. I'm planning to commit this soon.
        Michael Busch made changes -
        Attachment lucene-908.patch [ 12359104 ]
        Hide
        Hoss Man added a comment -

        A couple of random thoughts...

        1) macro's can take multiple optional named <element> tags to embed in their bodies ... so instead of declaring a refid for what to include in the metinf, callers of the macro could put <metainf> call directly in the call to <jarify>

        2) one way to reduce some redundancy in the build files (between jar-core, jar-demo, and war-demo) might be to use the <manifest> task instead of the <manifest> sub element of the <jar> task ... there are a few subtle differences but the main key is that the <manifest> taks let's you build up a file which you can then refer to by name from the <jar> task ... we could have a single <buildmanifest> macro with all of the common attributes in it and then it could be called from the various jar/war targets just before building the actual jar using attributes and <element> tags to customize things that need to be different.

        ...neither of these are crucial, they're just things you might want to consider to keep the build files smaller (and arguably simpler)

        Show
        Hoss Man added a comment - A couple of random thoughts... 1) macro's can take multiple optional named <element> tags to embed in their bodies ... so instead of declaring a refid for what to include in the metinf, callers of the macro could put <metainf> call directly in the call to <jarify> 2) one way to reduce some redundancy in the build files (between jar-core, jar-demo, and war-demo) might be to use the <manifest> task instead of the <manifest> sub element of the <jar> task ... there are a few subtle differences but the main key is that the <manifest> taks let's you build up a file which you can then refer to by name from the <jar> task ... we could have a single <buildmanifest> macro with all of the common attributes in it and then it could be called from the various jar/war targets just before building the actual jar using attributes and <element> tags to customize things that need to be different. ...neither of these are crucial, they're just things you might want to consider to keep the build files smaller (and arguably simpler)
        Hide
        Michael Busch added a comment -

        As always these are very good recommendations Hoss! I think I will commit my patch for 2.2, because it works fine. But I will leave this issue open (just clear the Fix version) to keep in mind that we want to make these improvements.

        Show
        Michael Busch added a comment - As always these are very good recommendations Hoss! I think I will commit my patch for 2.2, because it works fine. But I will leave this issue open (just clear the Fix version) to keep in mind that we want to make these improvements.
        Hide
        Michael Busch added a comment -

        Patch committed. Leaving this issue open for the simplifications suggested by Hoss.

        Show
        Michael Busch added a comment - Patch committed. Leaving this issue open for the simplifications suggested by Hoss.
        Michael Busch made changes -
        Fix Version/s 2.2 [ 12312328 ]
        Michael Busch made changes -
        Fix Version/s 2.3 [ 12312531 ]
        Hide
        Michael Busch added a comment -

        This patch:

        • removes the patternset "metainf.includes"; adds the optional element <metainf-includes> to the body of jarify
        • adds the macro "build-manifest" to common-build.xml to remove redundant code from the demo targets
        Show
        Michael Busch added a comment - This patch: removes the patternset "metainf.includes"; adds the optional element <metainf-includes> to the body of jarify adds the macro "build-manifest" to common-build.xml to remove redundant code from the demo targets
        Michael Busch made changes -
        Attachment lucene-908-new.patch [ 12364108 ]
        Hide
        Michael Busch added a comment -

        Committed. Revision: 568766

        Show
        Michael Busch added a comment - Committed. Revision: 568766
        Michael Busch made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Michael Busch made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Mark Thomas made changes -
        Workflow jira [ 12405589 ] Default workflow, editable Closed status [ 12561851 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12561851 ] jira [ 12582918 ]

          People

          • Assignee:
            Michael Busch
            Reporter:
            Michael Busch
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development