Re: woproject-ant-tasks appstart script doubt

From: Henrique Prange (hprang..mail.com)
Date: Wed May 13 2009 - 12:39:28 EDT

  • Next message: kenlist..nderhome.com: "Re: Ajax fails on deployment machine"

    Hi Chuck, Lachlan and Tim,

    D Tim Cummings wrote:
    > Hi Lachlan,
    >
    > I find it really useful to have the WOFrameworksBaseURL set in the
    > application start up file. I have modified the following two lines in
    > my build.xml so the app name contains a date and time stamp
    >
    > <property name="build.app.name" value="${project.name}${DSTAMP}${TSTAMP}" />
    > <property name="build.app.name.lowercase"
    > value="${project.name.lowercase}${DSTAMP}${TSTAMP}" />
    >
    > Then when I deploy, I can install the new version of the app alongside
    > the old version. In JavaMonitor I only have to change the "Path" to the
    > new version of the app and be confident that it will pick up the new
    > WebServerResources that were installed at the same time without having
    > to set the new WOFrameworksBaseURL in the "Additional Arguments".
    > Rolling back to a previous version of the app is similarly easy.
    >

    This is very similar to our approach. The Maven build generates
    artifacts with the version attached to the name (i.e. MyApp-1.0.woa). We
    have different versions of the same application running in the same
    instance of JavaMonitor occasionally.

    In this circumstance, the generated URLs for web resources are
    inconsistent without a properly WOFrameworkBaseURL configuration. I
    solved the problem using Maven filters. I've added the following entry
    to the application's Properties file.

    WOFrameworkBaseURL =
    /WebObjects/${project.build.finalName}.woa/Contents/Frameworks

    Maven replaces the ${project.build.finalName} variable for the correct
    name of the artifact during the build. It works, but I have to remember
    to add this information to every project (and every Maven user will).
    IMHO, the startup script generated by Maven builds should do that
    automatically. Otherwise it is producing an artifact that would probably
    be broken in deployment.

    On the other hand, it is a bad idea to add the launch argument if it
    drops the flexibility of configuration on JavaMonitor and Properties
    files for people that use different approach as Lachlan reported.

    So, the question remains: should this launch argument be added in the
    startup script of generated applications? I'm +1 for it if this change
    doesn't break everyone else's build.

    BTW, this modification also affects Ant builds. But I think it also make
    sense for Ant generated artifacts.

    Cheers,

    Henrique



    This archive was generated by hypermail 2.0.0 : Wed May 13 2009 - 12:40:43 EDT