"environment model" is my term :)
It's describes everything what is on the environment and can be
described.
Example:
<environment>
<envSettings>
<envSetting>
<variable></variable>
<value></value>
<envSetting>
</envSettings>
<envServers>
<envServer>
<envServerSettings>
</envServerSettings>
<envApplications>
<envApplicationSettings>
</envApplicationSettings>
<envApplication>
</envApplication>
</envApplications>
<envServers>
</environment>
Modello link - http://modello.codehaus.org/
Best regards,
Juri.
-----Original Message-----
From: Maarten Volders [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 07, 2007 12:51 PM
To: Maven Users List
Subject: Re: 1 artifact / environment VS 1 artifact / all environments
(best practice? Artifact naming problem)
Thanks for the feedback,
this is the first time I've heard about an 'environment model', could
you
elaborate a little on this, how this works of refer to some useful
sites?
What exactly are you putting in this environment model?
Could you provide a link to 'modello' because it seems my Google skills
are
disabled today :$
Grtz
On 6/7/07, Artamonov, Juri <[EMAIL PROTECTED]> wrote:
>
> You could have this working in several ways.
>
> 1. One artifact per environment using profiles. It's described on
Trygve
> Laugstol's blog page -
>
http://blogs.codehaus.org/people/trygvis/archives/001296_building_for_di
> fferent_environments_with_maven_2.html
>
> 2. Having one generic artifact for all environments actually this is
the
> way I'm doing.
> Here is what we developed.
> We have a build of the component which goes sequentially on all
> environments we need. It's has unique version and for this written
> defining build number mojo. Next created environment model (I created
it
> using modello) and written application which reads anything from
> environment model required for updating the package of the component.
> The application does updating the package to be environment specific
and
> deploy it using cargo on the required environment.
>
> There is one reason why we are following second way since we have
> unpredictable number of the environments since new projects coming and
> new environments appear including on customer's side and this is
already
> responsibility of the environment owner to have created environment
> model.
>
> Also having environment model allow to us to have clear picture of
what
> environment represents and what components are deployed there on what
> servers.
>
> Best regards,
> Juri.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Maarten Volders
> Sent: Thursday, June 07, 2007 10:18 AM
> To: [email protected]
> Subject: 1 artifact / environment VS 1 artifact / all environments
(best
> practice? Artifact naming problem)
>
> All,
>
> One of the things that is very unclear to me is you should have 1
> artifact /
> environment (test, staging, prod, ...) or have 1 artifact which works
on
> all
> environments? I would like to hear from people who successfully tried
> one or
> the other and have been using this for a while in production
> environments.
>
> Also perhaps some info on what approach you would take implementing
the
> one
> of the other (artifact naming, build cycle, repos, artifact naming...)
>
> I'm also dealing with a multi project structure.
>
> If having 1 artifact / environment, how would you deal with the
artifact
> names in a multi module environment? Can something like below be done?
>
> PARENT
>
> <project>
> <groupId>test</groupId>
> <artifactId>test${env}</artifactId>
> <packaging>pom</packaging>
> <version>0.1.0-SNAPSHOT</version>
>
> CHILD
>
> <project>
> <parent>
> <artifactId>test${env}</artifactId>
> <groupId>test</groupId>
> <version>0.1.0-SNAPSHOT</version>
> </parent>
>
> CHILD with dependencies
>
> <dependencies>
> <dependency>
> <groupId>${pom.groupId}</groupId>
> <artifactId>aaa${env}</artifactId>
> <version>0.1.0-SNAPSHOT</version>
> </dependency>
>
> And replacing ${env} by dev, test, prod ... but what about <version>
> 0.1.0-SNAPSHOT</version>,how do I deal with this? Or do I put the
${env}
> in
> version instead of artifactid? And what about using the release mgmt
> plugin
> in combination? As you see I'm totally confused about environment
> specific
> artifacts :-)
>
> Grtz
>
> ---------------------------------------------------------------------
> 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]
