Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-894

Custom build.xml for binary distributions

    Details

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

      Description

      The binary files of a distribution come with the demo sources
      and a build.xml file. However, the build.xml doesn't work for
      the binary distribution, so it can't be used to build the
      demos.

      This problem was notices the first time when release 2.1 was
      made. Before we ship 2.2 we should fix this.

      1. lucene-894.patch
        6 kB
        Hoss Man
      2. lucene-894.patch
        2 kB
        Hoss Man
      3. lucene-894.patch
        6 kB
        Michael Busch
      4. lucene-894.patch
        7 kB
        Michael Busch
      5. lucene-894.patch
        4 kB
        Michael Busch

        Activity

        Hide
        michaelbusch Michael Busch added a comment -

        This patch adds the new file "build-demo.xml" to the root directory. It
        becomes included in the binary distributions during packaging as "build.xml".

        It offers the targets "compile-demo", "jar-demo", "war-demo". This patch also
        includes "common-build.xml" in the binary distributions because
        "build-demo.xml" imports it.

        One drawback might be the following (or maybe not a big deal?):
        if you enter "ant -projecthelp" it shows you also the imported targets from
        common-build.xml like "common.jar-core", which are not needed (and not
        working) for the binaries. Is there a way to hide a subset of the imported
        targets? I admit that I am not the greatest ant expert ever , so help is
        highly appreciated.

        Show
        michaelbusch Michael Busch added a comment - This patch adds the new file "build-demo.xml" to the root directory. It becomes included in the binary distributions during packaging as "build.xml". It offers the targets "compile-demo", "jar-demo", "war-demo". This patch also includes "common-build.xml" in the binary distributions because "build-demo.xml" imports it. One drawback might be the following (or maybe not a big deal?): if you enter "ant -projecthelp" it shows you also the imported targets from common-build.xml like "common.jar-core", which are not needed (and not working) for the binaries. Is there a way to hide a subset of the imported targets? I admit that I am not the greatest ant expert ever , so help is highly appreciated.
        Hide
        hossman Hoss Man added a comment -

        minor notes...

        1) common-build.xml is a better name then "build-common.xml" like some other projects use because auto completion of file names on "b..." only result in build.xml ... perhaps this new file could be "demo-build.xml"

        2) as i recall, older versions of ant don't include the targets from imported files, but newer versions do ... the only way i know to supress them is to no provide them a description, which doesn't work well sicne we want them to have descriptions when imported by build.xml. a simple solution may be to keep the demo-build.xml file extremly simple, with no imports, and use <ant> or <antcall> to exec targets in common-build.xml (perhaps even new targets written explicitly for the demo)

        Show
        hossman Hoss Man added a comment - minor notes... 1) common-build.xml is a better name then "build-common.xml" like some other projects use because auto completion of file names on "b..." only result in build.xml ... perhaps this new file could be "demo-build.xml" 2) as i recall, older versions of ant don't include the targets from imported files, but newer versions do ... the only way i know to supress them is to no provide them a description, which doesn't work well sicne we want them to have descriptions when imported by build.xml. a simple solution may be to keep the demo-build.xml file extremly simple, with no imports, and use <ant> or <antcall> to exec targets in common-build.xml (perhaps even new targets written explicitly for the demo)
        Hide
        michaelbusch Michael Busch added a comment -

        > minor notes...

        Thanks for reviewing!

        > 1) common-build.xml is a better name then "build-common.xml" like some
        > other projects use because auto completion of file names on "b..." only
        > result in build.xml ... perhaps this new file could be "demo-build.xml"

        I see - will do.

        > 2) as i recall, older versions of ant don't include the targets from
        > imported files, but newer versions do ... the only way i know to supress
        > them is to no provide them a description, which doesn't work well sicne
        > we want them to have descriptions when imported by build.xml. a simple
        > solution may be to keep the demo-build.xml file extremly simple, with no
        > imports, and use <ant> or <antcall> to exec targets in common-build.xml
        > (perhaps even new targets written explicitly for the demo)

        If we want to use <ant> we have to move the demo targets from build.xml
        to common-build.xml. And demo-build.xml would have to overwrite some of
        the properties of common-build.xml like the classpath of the core
        classes, because build.xml builds from the sources, whereas demo-build.xml
        has to use the binary jar file.

        Actually I don't even need to import any targets from common-build.xml in
        demo-build.xml, all I need are some properties like version and build dir.
        A simpler solution which comes to my mind is it therefore to add a new
        file common-build.properties and to move some properties from
        common-build.xml to this new file. Then common-build.xml and
        demo-build.xml import the properties file and we're fine. I tried this out
        already and it seems to work fine. I will attach a patch with this
        approach. Would be nice if you could take another look, Hoss! (others are
        welcome too of course!)

        Show
        michaelbusch Michael Busch added a comment - > minor notes... Thanks for reviewing! > 1) common-build.xml is a better name then "build-common.xml" like some > other projects use because auto completion of file names on "b..." only > result in build.xml ... perhaps this new file could be "demo-build.xml" I see - will do. > 2) as i recall, older versions of ant don't include the targets from > imported files, but newer versions do ... the only way i know to supress > them is to no provide them a description, which doesn't work well sicne > we want them to have descriptions when imported by build.xml. a simple > solution may be to keep the demo-build.xml file extremly simple, with no > imports, and use <ant> or <antcall> to exec targets in common-build.xml > (perhaps even new targets written explicitly for the demo) If we want to use <ant> we have to move the demo targets from build.xml to common-build.xml. And demo-build.xml would have to overwrite some of the properties of common-build.xml like the classpath of the core classes, because build.xml builds from the sources, whereas demo-build.xml has to use the binary jar file. Actually I don't even need to import any targets from common-build.xml in demo-build.xml, all I need are some properties like version and build dir. A simpler solution which comes to my mind is it therefore to add a new file common-build.properties and to move some properties from common-build.xml to this new file. Then common-build.xml and demo-build.xml import the properties file and we're fine. I tried this out already and it seems to work fine. I will attach a patch with this approach. Would be nice if you could take another look, Hoss! (others are welcome too of course!)
        Hide
        michaelbusch Michael Busch added a comment -

        New patch:

        • renamed build-demo.xml to demo-build.xml
        • demo-build.xml does not import common-build.xml anymore
        • added a new file common-build.properties, imported by
          common-build.xml and demo-build.xml
        • demo-build.xml gets renamed to build.xml when packaged
        • binaries contain common-build.properties, not
          common-build.xml

        demo-build.xml has the following 4 targets:

        • clean
        • compile-demo
        • jar-demo
        • war-demo
        Show
        michaelbusch Michael Busch added a comment - New patch: renamed build-demo.xml to demo-build.xml demo-build.xml does not import common-build.xml anymore added a new file common-build.properties, imported by common-build.xml and demo-build.xml demo-build.xml gets renamed to build.xml when packaged binaries contain common-build.properties, not common-build.xml demo-build.xml has the following 4 targets: clean compile-demo jar-demo war-demo
        Hide
        michaelbusch Michael Busch added a comment -

        After updating my patch to the current trunk I noticed that something is
        not working correctly. It seems that the build.xml files of the contrib
        modules that import common-build.xml don't import the properties correctly
        that I moved to the new properties file. I actually have no idea why.

        But I'm not desperate yet and I got a new idea how to do this more
        elegant: In this new patch I add a file to the root dir called
        demo-build.template which has placeholder strings for the property values
        that are needed in the build.xml file of the binary package like
        "version". While packaging this template file becomes copied to the build
        dir and via the ant task <replace> the placeholder strings are replaced by
        the actual values. Then this file is included as build.xml in the binary
        packages.

        The advantage of this approach is that we don't have to include
        common-build.xml or a property file in the binaries. Just a very simple
        build.xml is included with the 4 targets "clean", "compile-demo",
        "jar-demo", "war-demo". I decided not to dig into the problem with the
        previous patch described above because I believe this is the better
        approach. Thoughts?

        Show
        michaelbusch Michael Busch added a comment - After updating my patch to the current trunk I noticed that something is not working correctly. It seems that the build.xml files of the contrib modules that import common-build.xml don't import the properties correctly that I moved to the new properties file. I actually have no idea why. But I'm not desperate yet and I got a new idea how to do this more elegant: In this new patch I add a file to the root dir called demo-build.template which has placeholder strings for the property values that are needed in the build.xml file of the binary package like "version". While packaging this template file becomes copied to the build dir and via the ant task <replace> the placeholder strings are replaced by the actual values. Then this file is included as build.xml in the binary packages. The advantage of this approach is that we don't have to include common-build.xml or a property file in the binaries. Just a very simple build.xml is included with the 4 targets "clean", "compile-demo", "jar-demo", "war-demo". I decided not to dig into the problem with the previous patch described above because I believe this is the better approach. Thoughts?
        Hide
        michaelbusch Michael Busch added a comment -

        Has anybody objections against the approach in the latest
        patch? If not, I will commit this in a day or two.

        Show
        michaelbusch Michael Busch added a comment - Has anybody objections against the approach in the latest patch? If not, I will commit this in a day or two.
        Hide
        hossman Hoss Man added a comment -

        Michael: this approach seems great. I couldn't help but make a few tweaks...

        1) used a filterset to do the token replacements as part of hte copy (isntead of after the fact)
        2) since the demo build file is now just a template (and can't be run until it's pacakged) it now seems more like "source" then part of the build system, so i moved it into "src/demo" (which has the added benefit of keeping the root dir a little cleaner)

        Show
        hossman Hoss Man added a comment - Michael: this approach seems great. I couldn't help but make a few tweaks... 1) used a filterset to do the token replacements as part of hte copy (isntead of after the fact) 2) since the demo build file is now just a template (and can't be run until it's pacakged) it now seems more like "source" then part of the build system, so i moved it into "src/demo" (which has the added benefit of keeping the root dir a little cleaner)
        Hide
        hossman Hoss Man added a comment -

        whoops ... forgot to svn add src/demo/demo-build.template after i moved it .. it has some minor changes because of how i setup the <filterset>

        Show
        hossman Hoss Man added a comment - whoops ... forgot to svn add src/demo/demo-build.template after i moved it .. it has some minor changes because of how i setup the <filterset>
        Hide
        michaelbusch Michael Busch added a comment -

        > I couldn't help but make a few tweaks...

        Thanks for reviewing!

        > 1) used a filterset to do the token replacements as part of hte copy
        > (isntead of after the fact)

        Neat!

        > 2) since the demo build file is now just a template (and can't be run
        > until it's pacakged) it now seems more like "source" then part of the
        > build system, so i moved it into "src/demo" (which has the added benefit
        > of keeping the root dir a little cleaner)

        Good! Yes I agree that src/demo is a better place for the template file.

        Show
        michaelbusch Michael Busch added a comment - > I couldn't help but make a few tweaks... Thanks for reviewing! > 1) used a filterset to do the token replacements as part of hte copy > (isntead of after the fact) Neat! > 2) since the demo build file is now just a template (and can't be run > until it's pacakged) it now seems more like "source" then part of the > build system, so i moved it into "src/demo" (which has the added benefit > of keeping the root dir a little cleaner) Good! Yes I agree that src/demo is a better place for the template file.
        Hide
        michaelbusch Michael Busch added a comment -

        Works great, Hoss! Thanks again. I just committed this.

        Show
        michaelbusch Michael Busch added a comment - Works great, Hoss! Thanks again. I just committed this.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development