Hi there
I had to solve a similar problem, but not with an ear. My build process
produces a bunch of archives that
at some point need to deployed in a target environment (a proprietary
ESB in that case). I have done a prototype
that does the following (quite elaborate, but seems to be working):
1. I build the archives and using a custom plugin and have a parameter
file that notes, which variables that
archive accepts for configuration.
2. I have defined what I call a business application. That one has
dependancies to all the archives I require,
Another plugin gets the business app dependancies, packages them up
and assembles the deployment paramters
into one configuration file that my ESB can understand.
3. Finally i keep the configuration instances in separate
"configuration" projects, so that I can define a top
level deployment project, that has a dependancy to the business
application and one instance of deployment
parameters. A custom plugin uses that project definition to automate
the complete deployment into a given
target environment. Porting from A to B just requires a new instance
of the configuation project.
I admit, it took us quite a while to get the plugin stuff figured out
and everything plays together, but in the end
it seems to be a good approach.
HTH
Andreas
[EMAIL PROTECTED] schrieb:
Hi,
I know about filtering - but that´s not what I want exactly.
My problem is that we build (and deploy) the ear at one time (filtering is
done at build time), but the delivery of the ear into our product (ears,
wars, documentation and so on) is separated.
I need to patch the ear at delivery time to introduce some customer
specific properties.
This is because we ship exactly the same ear to different customers -
differing only in one properties file, located in the ear.
One solution could be to build the ear only at delivery time, where the
customer is known - but that´s not what i want, because we also need the
ear at developement time,
where the customer is unknown...
Thanx, Torsten
Kristian Rink <[EMAIL PROTECTED]>
Gesendet von: news <[EMAIL PROTECTED]>
14.07.2008 14:35
Bitte antworten an
"Maven Users List" <[email protected]>
An
[email protected]
Kopie
Thema
Re: replace content (properties file) of deployed artifacts for custom
purposes?
Torsten;
[EMAIL PROTECTED] schrieb:
# Datum des Builds
build.startDate=${build.startDate}
# Buildversion
productVersion=${productVersion}
I believe that maven resource filtering does pretty much what you want,
only I am not sure how / whether or not to determine things like
"build.startDate" to be automatically included in there:
http://maven.apache.org/guides/getting-started/index.html#How_do_I_filter_resource_files
Cheers,
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
