Argh!!!!
You're doing it wrong.
The JAR/WAR/EAR/etc should be independent of the environment in which
it works. If you want to bundle default properties for when no
properties file is to be found, that is fine. But it is a great
ANTI-PATTERN to put environment specific resources into your
artifacts.
Maven is going to fight you all the way.
Here is how you would do things with a .war/.ear file, where there are
a number of options (a subset of the options works for .jar files):
* Use context parameters in the servlet/application container
* Use JNDI to expose the parameters
* Use System properties to expose the configuration
* Put the environment specific parameters in resource files on the classpath
* Use a repackaging script immediately prior to deployment to the
container that unpacks the archive, adds the configuration files, and
repacks it
All of these are considered outside the scope of Maven.
Maven's responsibility for building your artifact ends when it has
delivered an environment independent artifact into the Maven
Repository.
Your responsibility does not end there. To then (I am going to use the
word 'ship' in place of 'deploy' because people confuse maven's use of
'deploy' with application container, and operations teams use of the
word) ship your application, you take the artifact from the Maven
Repository, configure it (if necessary) for the environment in which
it will be shipped and put it into that environment.
If you want Maven to help with that, I would take a look at the
ship-maven-plugin@mojo or the cargo set of plugins... both of which
operate, in this context, outside of the standard Maven lifecycle,
i.e. after Maven has completed its responsibilities.
HTH
-Stephen
On 29 February 2012 00:51, Billy Newman <newman...@gmail.com> wrote:
> So for reasons I don't want to get into I have a jar that is backed by a
> properties file. That properties file is different for different
> environments. What I want to end up with is something like:
>
> myapi-1.0-dev.jar
> myapi-1.0-test.jar
> myapi-1.0-ops.jar
>
> Where dev, test, and ops are different flavors of the jar specified by the
> classifier.
>
> My real question was is how do I set the classifier such that it would create
> one of these. The answer is in the maven-jar-plugin you can set a
> configuration with a classifier.
>
> <classifier>${env}</classifier>
>
> Then I setup a Jenkins build that will execute a deploy for each of my
> flavors by setting the env property differently for each execution.
>
> env=dev
> env=test
> env=ops
>
> Then when I or anyone makes changes to the jar they can update the version in
> the Pom file and run he Jenkins task to deploy all three flavors. Making them
> all available for all groups to grab out of my repository.
>
> Sent from my iPhone
>
> On Feb 28, 2012, at 3:26 PM, "Manfred Moser" <manf...@mosabuam.com> wrote:
>
>> On Tue, February 28, 2012 2:13 pm, Benson Margulies wrote:
>>> Let me try to arrange the explanation here in good order.
>>>
>>> Classifiers were not designed to allow for 'different flavors of one
>>> artifact'. They were designed to allow an artifact to have an
>>> entourage, such as its sources or javadoc.
>>>
>>> So, to begin with, there's no way to ask Maven to set a non-""
>>> classifier for the main artifact with packaging jar.
>>>
>>> Further, there are corner cases of dependency management that will get
>>> you in this case.
>>>
>>> The maven model is really that you would use different artifactIds for
>>> the different 'flavors'. You might accomplish this with an aggregating
>>> pom and a bunch of modules, one per flavor, for example.
>>>
>>> No it's not entirely satisfactory. This is just not a case that Maven
>>> is designed to support well, and you should seriously consider
>>> alternatives.
>>
>> While I agree with Benson if you still want to make it happen you could
>> use the build helper plugin with the attachArtifact goal.
>>
>> manfred
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
