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
        5 kB
        Hoss Man
      2. lucene-908.patch
        11 kB
        Michael Busch
      3. lucene-908-new.patch
        15 kB
        Michael Busch

        Issue Links

          Activity

          Hide
          Michael Busch added a comment -

          Committed. Revision: 568766

          Show
          Michael Busch added a comment - Committed. Revision: 568766
          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
          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.
          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
          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 -

          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.
          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 -

          > 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
          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?
          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 -

          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 -->
          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.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development