Another approach I forgot to mention was to have separate "environment"
jars that can be added to each environment to bring it in line with some
maximal standard, and then write all services assuming the environment
provides that standard.

Andrew

andrew cooke wrote:
>
> Hi,
>
> Does anyone have any advice on decoupling build and deployment in a
> multiproject system where components can be deployed in several different
> environments?
>
> We have a service oriented architecture, and some components can be
> deployed in various different ways.  We can also separate components into
> message/process and service sub-components, where the message/process part
> typically has much smaller dependencies.
>
> At the moment we are considering a structure like:
>
> root
>  +- pom describing project-wide settings
>  +- iface
>  |   +- pom describing message/process dependencies
>  |   +- comp1-iface
>  |   |   +- pom and code for comp1 message/process sub-component
>  |   +- comp2-iface
>  |   |   +- pom and code for comp2 message/process sub-component
>  |   : etc
>  +- j2ee
>  |   +- pom describing j2ee deploy environment (supplied jars)
>  |   :   +- comp1-service
>  |       |   +- pom and code for comp1 services
>  |       +-comp1-ear
>  |           +- pom for packaging comp1
>  +- spring
>      +- pom describing spring deploy environment
>      :   +- comp2-service
>          |   +- pom and code for comp2 services
>          +- comp2-jar
>              +- pom for packaging comp2
>
> This specifies the correct dependencies for compiling/packaging, but means
> that code for the service components is fixed under one deploy
> environment.  Since we spend a fair amount of engineering effort making
> our components deployable in multiple environments this is rather
> annoying.  When we want to change the deploy of a component we need to
> move its location!
>
> Clearly this is not good.  How do people manage this better?  We have
> considered making the environment a project (jar) that is depended on
> explicitly, rather than as something inherited from the pom.  But that
> "felt wrong" - maven seems to use pom inheritance for this.  Or am I
> mistaken?
>
> Thanks,
> Andrew
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to