Ah! Your use case is not internal app use/release, but public distribution to
uncontrolled environments. :-) You can tell how I answered the question...
In your context, I agree that option 4 isn't very good (unless you want to dump
on the customer to get the environment specific dependencies on the system
classpath!). It has worked well for me in internally controlled environments.
Option 3 may still have merit, depending on other considerations of your
context. As you said, it is "moving the problem elsewhere", but it is as
intended per spec. Using the container to shield the app from environmental
config items is perfectly valid. Many ops groups actually prefer this approach
as it gives them some customization/control too.
Now, if only each container had "nice & friendly" (tm) config feature ;-).
Which containers are you specifically targeting? (particularly wondering
commercial, FOS, or both).
So yes, you'll probably end up with multiple builds not for run-type (dev, QA,
prod) environments, but for user configurations.
And I don't think either Maven version provides the facility to fully provide
what you are looking for (if it does, I'm ready and impatiently waiting to
learn! ;-)
Quoting Vincent Massol <[EMAIL PROTECTED]>:
> Hi Jeff,
>
> On Mar 16, 2007, at 1:00 PM, Jeff Jensen wrote:
>
> > I do my best to avoid needing a separate build per environment. A
> > release
> > is a release, and while reproducibility is not the issue, I find it
> > silly to
> > do so.
> >
> > In my customer work, I found two key strategies that have worked
> > well, both
> > from "new system" and streamlining an existing system:
> >
> > Option 3
> > --------
> > Use container configuration. Just get the DataSource for a
> > connection. For
> > other info, set properties and/or servlet context params.
>
> You're just moving the problem elsewhere! :)
>
> You'll still need to configure those datasources in your container
> config file.
>
> > Option 4
> > --------
> > Include all property files in the artifact, and the environment
> > determines
> > which one is used:
> > - Have a base name for the set of property files, e.g.
> > app.properties.
> > - Set an environment variable on each runtime environment, e.g.
> > APP_ENV=dev, APP_ENV=test, APP_ENV=prod.
> > - Have the code load props from app_${APP_ENV}.properties. Or use
> > the env
> > var as a directory name for a collection of env specific files, e.g.
> > ${APP_ENV}/app.properties.
>
> I don't like this approach too much as:
> 1) the app becomes bloated. For example it means adding the MySQL +
> HSQL DB + Oracle + PostGreSQL driver jars.... It starts to add up...
> 2) it's not as nice for the end user as you need to explain to him
> that he needs to set some env variable, etc, whereas in the approach
> where you make the different distributions available, he just picks
> the one he wants and it works out of the box
>
> Thanks for your inputs!
> -Vincent
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 16, 2007 6:39 AM
> > To: Maven Users List
> > Subject: What is the Best practice for generating variations of an
> > artifacts?
> >
> > Hi,
> >
> > I've never found a good answer to this use case so far so I'm
> > curious about
> > how others have implemented it.
> >
> > Imagine a project that generates a WAR. This WAR contains a config
> > file (say
> > in WEB-INF/classes) that configures connection parameters for the
> > database.
> >
> > Now imagine that your project wants to support several databases
> > and you
> > want the ability to build for a given database.
> >
> > I see 2 options:
> >
> > Option 1
> > -----------
> >
> > * Use filtering
> > * Use profiles to set the values for the different databases
> >
> > Issues:
> >
> > * In order to differentiate the generate WAR file name you'll need
> > to use
> > <finalName> but the value set there won't be used for install/
> > deploy which
> > means that the WAR files users will see will always be the same.
> >
> > Idea for future:
> >
> > * It would be nice if Maven had a <classifier> element under
> > <project> so
> > that it would be possible to generate an artifact with a classifier.
> >
> > Option 2
> > -----------
> >
> > * Create one module per database, under a parent module
> > * Create profiles in the parent module to conditionally include the
> > <module>
> > to be built
> >
> > Issues:
> >
> > * Very heavy (one module per database) especially when the only
> > difference
> > between the generated artifacts is only 3 lines in a config file
> > * Need a way to share common configuration between the modules, in
> > order to
> > prevent duplication. For example if the config files only contains
> > 3 lines
> > that are different for each database and there are 100 lines in
> > total, you
> > don't want to duplicate the 97 lines in as many modules as you have
> > databases
> >
> > What do people do? Is there some plan to support this use case in a
> > better
> > fashion in the future?
> >
> > Thanks
> > -Vincent
> >
> >
> > ---------------------------------------------------------------------
> > 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]
> >
>
>
> ---------------------------------------------------------------------
> 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]
