maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: How to deploy with 'classifier'
Date Wed, 29 Feb 2012 18:47:15 GMT
On Wed, Feb 29, 2012 at 9:03 AM, Ron Wheeler
<> wrote:
> Great explanation.
> Could I put this up on my technical blog where it can be referenced?
> This comes up at least once a month and really needs a clear explanation
> such as you have given.


> If you agree, can you give me an attribution line that I can add to indicate
> that you are the author.
> If you want to add links or a short description, I would be pleased to
> include them.
> You can check out the blog at
> I would appreciate any comments on the JNDI article or any other article.
> I do not get a lot of traffic but at least it is a place to refer people
> rather than writing a long note each time.
> Ron
> On 29/02/2012 6:02 AM, Stephen Connolly wrote:
>> 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<>  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"<>
>>>  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:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email:
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message