Re: Build.xml and build.properties.

From: Ulrich Köster (ulric..bjectstyle.org)
Date: Sat Sep 27 2003 - 12:09:23 EDT

  • Next message: Anjo Krank: "Re: FREQ: property setting for /build output directory for internal builds."

    Hi Christian,

    thanks for the contribution. It could take some time until the stuff
    get into cvs. Please be patient.

    Ulrich

    On 26.09.2003, at 19:25, Christian Edward Gruber wrote:

    > Hi guys and gals,
    >
    > Uli wrote:
    >> Removing the EOModel from the project does not delete the
    >> EOModel in the product.
    >
    > I was thinking about this, especially since I have a DataModel
    > framework
    > that I basically have to install everytime I change the model, so I
    > rewrote the build.xml and added extra bits to build.xml. It should be
    > a
    > bit more generic, and works very well for me. It also has the
    > beginnings of a "compile" target that runs if not in eclipse. Note the
    > defaults are particular to my style of project layout, and should be
    > changed in build.xml for your benefit, but they can always be
    > overridden
    > in build.properties anyways.
    >
    > Perhaps there's something here useful to the main build.xml's. Note, I
    > use a similar thing for build.xml in Woa. In fact, with the changes I
    > made, they are now even more similar (woapp and framework's build.xml
    > files).
    >
    > Major operational changes (not counting internal organization) are
    > additional overiddable properties for file/folder locations, added a
    > package target (to roll up a version-labeled .zip file of the
    > framework/app), and an install target, which requires the package to be
    > built (for sanity) and then unzips it into (by default)
    > WOLOCALROOT/Library/{Frameworks|WebObjectsApplications}.
    >
    > One other feature (related to the quoted message) is that it deletes
    > each old artifact (or tries to) before preparing it. So before
    > creating
    > the ./build/Whatever.framework, it deletes the old framework folder
    > then
    > prepares the new one. This has helped dramatically with things like
    > Eomodels since it forces you to have the latest, or be informed that
    > the
    > deletion failed. Saved hours of what used to be a process of chasing
    > down non-existant bugs that were build errors.
    >
    > The attached build.xml is for frameworks. The one for apps is almost
    > identical, and I'll send it out in a minute.
    >
    > Regards,
    > Christian.
    >
    >
    > <build.xml><build.properties>

    This archive was generated by hypermail 2.0.0 : Sat Sep 27 2003 - 12:09:22 EDT