Maven
  1. Maven
  2. MNG-416

best practices: multiple profile deployments

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Trivial Trivial
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      There have been several threads on the user and dev list following on from the recommendations made in the best practices document.

      The objective is to make an artifact standalone, without the need to rebuild to deploy to a new environment. Configuration should be externalised (or all stored inside and selected based on an externalised parameter). This can usually be done with JNDI in J2EE (especially for database configurations), but this has a couple of limitations:

      • JNDI can be awkward and may not be available outside of the container (though directory-naming can be used)
      • some things in the deployment descriptor must be inside the artifact, but need to be different between environments (eg security settings in web.xml and a bunch of weblogic specific files for which the container does not provide external/admin based configuration for).

      Some products to consider:

        Activity

        Hide
        Jason van Zyl added a comment -

        A couple other projects that might be of use are jConfig (http://www.jconfig.org/) for configuration management and SmartFrog for the deployments themselves (http://www.hpl.hp.com/research/smartfrog/)

        Show
        Jason van Zyl added a comment - A couple other projects that might be of use are jConfig ( http://www.jconfig.org/ ) for configuration management and SmartFrog for the deployments themselves ( http://www.hpl.hp.com/research/smartfrog/ )
        Hide
        John Casey added a comment -

        this looks more like some sort of tool development than simply writing a document to indicate a "best practice" that effectively endorses one of these solutions...

        Assuming we want to write a config tool like this, would Maven really be a good home for it? It'd be more of a runtime tool, rather than a development tool...

        Assuming we don't want to write a tool, is it really appropriate for us to endorse another tool over the rest? Is there a clear winner in the problem space right now, under all circumstances?

        Show
        John Casey added a comment - this looks more like some sort of tool development than simply writing a document to indicate a "best practice" that effectively endorses one of these solutions... Assuming we want to write a config tool like this, would Maven really be a good home for it? It'd be more of a runtime tool, rather than a development tool... Assuming we don't want to write a tool, is it really appropriate for us to endorse another tool over the rest? Is there a clear winner in the problem space right now, under all circumstances?

          People

          • Assignee:
            Unassigned
            Reporter:
            Brett Porter
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: