Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 0.5
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Number of attachments :
      0

      Description

      From mailing-list:

      "Hi,

      I think it could be interesting for Cargo to have a configuration file. We could have a Factory that reads such a config file and generates a Container object that is setup accordingly. The same can be done for saving an existing configuration.

      A typical cargo.xml config file would be:

      <cargo>
      <containers>
      <container id="xxx" key="resin3x"
      homeDir="c:/apps/resin-3.0.9</homeDir>"
      output="$

      {basedir}/target/resin-cargo.log"
      append="false"
      log="{basedir}

      /target/resin-log.log">
      <zipUrlInstaller
      installUrl="http://www.caucho.com/download/resin-3.0.9.zip"
      installDir="$

      {basedir}/target/install"/>
      </zipUrlInstaller>
      <configuration hint="standalone"
      dir="${basedir}

      /target/resin">
      <property name="cargo.servlet.port" value="8280"/>
      <property name="cargo.logging" value="high"/>
      </configuration>
      </container>
      </containers>
      </cargo>

      Note 1:
      -------

      From Java:
      Container[] containers = new CargoFactory().loadCargoConfigurations(File)
      Container container = new CargoFactory().loadCargoConfiguration(String id,
      File)
      new CargoFactory().saveCargoConfiguration(Container, File)

      This CargoFactory would sit in the Generic Java API module (see http://cargo.codehaus.org/download/attachments/8416/access-layers.jpg). Note that currently this module is still in the cargo/core/container/ subproject but we would possibly want to separate it one day.

      Note 2:
      -------

      The current <cargo-*> Ant tasks or the future <container> task would accept either a nested configuration or a configurationFile attribute:

      <cargo-resin3x... key="resin3x"
      homeDir="c:/apps/resin-3.0.9</homeDir>"
      output="$

      {basedir}/target/resin-cargo.log"
      append="false"
      log="{basedir}

      /target/resin-log.log">
      <zipUrlInstaller
      installUrl="http://www.caucho.com/download/resin-3.0.9.zip"
      installDir="$

      {basedir}/target/install"/>
      </zipUrlInstaller>
      <configuration hint="standalone"
      dir="${basedir}

      /target/resin">
      <property name="cargo.servlet.port" value="8280"/>
      <property name="cargo.logging" value="high"/>
      </configuration>
      </cargo-resin3x>

      Or

      <cargo-resin3x... configurationFile=".../cargo.xml"/>

      Advantages
      ----------

      • Ability to read and persist configurations. This would be useful for example for the Netbeans plugin where Milos needed a way to do this.
      • Independent way of specifying a Cargo configuration (this can work in the same manner for the Java, Ant or Maven integration). This also leads to more coding sharing between the different integration modules.
      • Scales better than having to specify flat properties. For example the Maven plugin is currently configured in the following manner:

      cargo.containers = myResin
      cargo.zipUrlInstaller.myResin.installUrl = ...
      cargo.zipUrlInstaller.myResin.installDir = $

      {maven.build.dir}/installs cargo.container.myResin.containerKey = resin3x cargo.container.myResin.homeDir = c:/apps/resin-3.0.9 cargo.container.myResin.config.hint = standalone cargo.container.myResin.config.dir = ${maven.build.dir}

      /resin cargo.container.myResin.config.standalone.servlet.port = 8280 cargo.container.myResin.config.standalone.logging = high

      WDYT?

      Thanks
      -Vincent
      "

        Activity

        Hide
        Vincent Massol added a comment -

        Ok, I have implemented it on my machine (not committed)... but I now think
        it was a bad idea!

        I now think that having a common configuration mechanism for the different
        integrations (Ant, Maven, Netbeans, etc) is an illusion and will lead to a
        less integrated solution. Indeed, each integration has it own mechanism for
        specifying a configuration and they're all different. Providing a separate
        XML config file will only avoid using the default configuration mechanism
        provided by these tools...

        Let see some examples:

        • Ant has a reflection-based strategy and an engine that reads XML file and
          calls setXXX and createXXX methods from the Ant tasks. Thus if we want to
          support the following we won't be able to use our XML configuration reader
          (unless we implement the same XML mapping strategy as Ant):

        <cargo-resin3x... key="resin3x"
        homeDir="c:/apps/resin-3.0.9</homeDir>"
        output="$

        {basedir}/target/resin-cargo.log"
        append="false"
        log="{basedir}

        /target/resin-log.log">
        <zipUrlInstaller
        installUrl="http://www.caucho.com/download/resin-3.0.9.zip"
        installDir="$

        {basedir}/target/install"/>
        </zipUrlInstaller>
        <configuration hint="standalone"
        dir="${basedir}

        /target/resin">
        <property name="cargo.servlet.port" value="8280"/>
        <property name="cargo.logging" value="high"/>
        </configuration>
        </cargo-resin3x>

        • In addition there was a proposal to create several Ant tasks which would
          no longer work with this notion of a single XML config file.
        • For Maven it would seem ok at first glance. However it's not... Imagine
          having an XML config. Now, some of the attributes/elements of this file are
          environment-dependent (port, location of container, etc). So this means I'll
          need to parametrize this XML config file and the parameters will be...
          properties... Back to square one... Also, having an environment-dependent
          XML config file and an environment-independent one and merging the 2 is
          going to be complex. Properties are easier in this case.
        • Maven 2 has yet another configuration mechanism.

        Etc.

        Thus, my conclusion is that each integration has to provide its own way for
        configuring Cargo.

        Show
        Vincent Massol added a comment - Ok, I have implemented it on my machine (not committed)... but I now think it was a bad idea! I now think that having a common configuration mechanism for the different integrations (Ant, Maven, Netbeans, etc) is an illusion and will lead to a less integrated solution. Indeed, each integration has it own mechanism for specifying a configuration and they're all different. Providing a separate XML config file will only avoid using the default configuration mechanism provided by these tools... Let see some examples: Ant has a reflection-based strategy and an engine that reads XML file and calls setXXX and createXXX methods from the Ant tasks. Thus if we want to support the following we won't be able to use our XML configuration reader (unless we implement the same XML mapping strategy as Ant): <cargo-resin3x... key="resin3x" homeDir="c:/apps/resin-3.0.9</homeDir>" output="$ {basedir}/target/resin-cargo.log" append="false" log="{basedir} /target/resin-log.log"> <zipUrlInstaller installUrl="http://www.caucho.com/download/resin-3.0.9.zip" installDir="$ {basedir}/target/install"/> </zipUrlInstaller> <configuration hint="standalone" dir="${basedir} /target/resin"> <property name="cargo.servlet.port" value="8280"/> <property name="cargo.logging" value="high"/> </configuration> </cargo-resin3x> In addition there was a proposal to create several Ant tasks which would no longer work with this notion of a single XML config file. For Maven it would seem ok at first glance. However it's not... Imagine having an XML config. Now, some of the attributes/elements of this file are environment-dependent (port, location of container, etc). So this means I'll need to parametrize this XML config file and the parameters will be... properties... Back to square one... Also, having an environment-dependent XML config file and an environment-independent one and merging the 2 is going to be complex. Properties are easier in this case. Maven 2 has yet another configuration mechanism. Etc. Thus, my conclusion is that each integration has to provide its own way for configuring Cargo.

          People

          • Assignee:
            Vincent Massol
            Reporter:
            Vincent Massol
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: