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]
