Re: Releasing/Deploying multiple artefacts with maven-assembly-plugin : what is your opinion ?
Thanks for the prompt replies :-) I didn't precise I was not at an Application layer, but in a layer above. I confirm that on the Application layer, Spring answers really well about the problematic. For example, my packaging will produce a complete archive with tomcat bundled into it. In the tomcat configuration, I have to pack some load balancing configuration props (jvmRoute attribute in server.xml for example). These properties are environnment dependent too (on dev envs, I won't have to use load balancing, but in production env, I'll have to) Frédéric On Fri, Feb 4, 2011 at 2:00 AM, Wendy Smoak wsm...@gmail.com wrote: On Thu, Feb 3, 2011 at 6:48 PM, Frederic Camblor fcamb...@gmail.com wrote: Nobody has any piece of advice against these options ? :( When you tell us you can't change anything, there's not much to say. Either move the configuration out of the war, or put it *all* in there and use something (like Spring) that can sense which environment it is running in and select the right config file. In any case, you want *one* artifact that can be used in the different environments. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Releasing/Deploying multiple artefacts with maven-assembly-plugin : what is your opinion ?
Nobody has any piece of advice against these options ? :(
On Sun, Jan 30, 2011 at 3:13 AM, Frederic Camblor fcamb...@gmail.comwrote:
Hi all !
My context :
- 1 pom Artefact
- This artefact generate N zip artefacts via the maven-assembly-plugin.
These N artefact are contextualized upon a target deployment environnment.
- N = ~5 for the moment, but it can evolve depending on the number of
environnment that will grow in the future
- The N artefacts are not inevitably used (staging)
- I can't change my zip artefact content/architecture (let's say it's fixed
by my customer)
- My zip artefacts are relatively big (~200Mo each)
- They diverge only by 4-5 configuration files packed into the zip at
different places
- I'm frequently releasing using maven-release-plugin. Build
reproductibility is a top level requirement.
I'm wondering about the best approach to take to have something viable for
the project.
I already listed 3 way of agencing my pom :
1/ I use N maven-assembly-plugin executions, with different descriptor
/ filters
Drawbacks :
- mvn package take a lng time because it archives N * 200Mo files
- when launching release:perform (and thus, calling the deploy goal), I
deploy N*200Mo files in my maven repository ... even if I don't use the
artefacts in every deployment environnment. I find it really overdimensioned
since only a few configuration files differ between my N artefacts :(
2/ I use only 1 maven-assembly-plugin execution with variabilized
descriptor / filters.
For example :
descriptorassemblies/${target.env}-assembly.xml/descriptor
When building, I must set -Dtarget.env property key to switch between
environnments
Drawbacks :
- Doesn't satisfy the build reproductibility requirement very well, since I
must specify my target environnment during the build and during the tag (and
this information is nowhere persisted)
3/ Same as 2/ except that I put maven-assembly-plugin configuration into an
inactive profile.
That is, by default, no zip artefact will be produced during mvn package.
During release:prepare, I will only tag the pom and the assemblies
configuration files.
When calling release:perform, I'll have to specify a -Dtarget.env to
determine on which environnment I want to deploy my artefact.
My artefact will then be uploaded on my maven repository, too.
Drawbacks :
- I must separate my release:prepare release:perform calls in my CI
server. The first one will be called once for a release. The second one will
be called several times after release:prepare, to deploy my artefact on my N
environnments.
Obviously, I find the 3rd choice the best one...
I'm interested in your feedback / opinion on the question. Is there a
silver bullet here ?
Frédéric
Re: Releasing/Deploying multiple artefacts with maven-assembly-plugin : what is your opinion ?
On 3 February 2011 15:48, Frederic Camblor fcamb...@gmail.com wrote: Nobody has any piece of advice against these options ? :( N artifacts is (as I think you've already discovered) not very scalable. :-) So take the configuration out of the WAR. Create a single WAR that can be (re)used by all environments. Use a known (relative) file location, a known URL, or some other way to find/access the configuration at runtime. I'm sure it will take some effort in the short term but the long term benefits should be obvious. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Releasing/Deploying multiple artefacts with maven-assembly-plugin : what is your opinion ?
On Thu, Feb 3, 2011 at 6:48 PM, Frederic Camblor fcamb...@gmail.com wrote: Nobody has any piece of advice against these options ? :( When you tell us you can't change anything, there's not much to say. Either move the configuration out of the war, or put it *all* in there and use something (like Spring) that can sense which environment it is running in and select the right config file. In any case, you want *one* artifact that can be used in the different environments. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Releasing/Deploying multiple artefacts with maven-assembly-plugin : what is your opinion ?
Hi all !
My context :
- 1 pom Artefact
- This artefact generate N zip artefacts via the maven-assembly-plugin.
These N artefact are contextualized upon a target deployment environnment.
- N = ~5 for the moment, but it can evolve depending on the number of
environnment that will grow in the future
- The N artefacts are not inevitably used (staging)
- I can't change my zip artefact content/architecture (let's say it's fixed
by my customer)
- My zip artefacts are relatively big (~200Mo each)
- They diverge only by 4-5 configuration files packed into the zip at
different places
- I'm frequently releasing using maven-release-plugin. Build
reproductibility is a top level requirement.
I'm wondering about the best approach to take to have something viable for
the project.
I already listed 3 way of agencing my pom :
1/ I use N maven-assembly-plugin executions, with different descriptor /
filters
Drawbacks :
- mvn package take a lng time because it archives N * 200Mo files
- when launching release:perform (and thus, calling the deploy goal), I
deploy N*200Mo files in my maven repository ... even if I don't use the
artefacts in every deployment environnment. I find it really overdimensioned
since only a few configuration files differ between my N artefacts :(
2/ I use only 1 maven-assembly-plugin execution with variabilized
descriptor / filters.
For example :
descriptorassemblies/${target.env}-assembly.xml/descriptor
When building, I must set -Dtarget.env property key to switch between
environnments
Drawbacks :
- Doesn't satisfy the build reproductibility requirement very well, since I
must specify my target environnment during the build and during the tag (and
this information is nowhere persisted)
3/ Same as 2/ except that I put maven-assembly-plugin configuration into an
inactive profile.
That is, by default, no zip artefact will be produced during mvn package.
During release:prepare, I will only tag the pom and the assemblies
configuration files.
When calling release:perform, I'll have to specify a -Dtarget.env to
determine on which environnment I want to deploy my artefact.
My artefact will then be uploaded on my maven repository, too.
Drawbacks :
- I must separate my release:prepare release:perform calls in my CI
server. The first one will be called once for a release. The second one will
be called several times after release:prepare, to deploy my artefact on my N
environnments.
Obviously, I find the 3rd choice the best one...
I'm interested in your feedback / opinion on the question. Is there a silver
bullet here ?
Frédéric
