maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billy Newman <>
Subject Re: How to deploy with 'classifier'
Date Wed, 29 Feb 2012 14:36:02 GMT
I have a solution that already works, is what I am really trying to say. 

Rather than keep it to myself I thought I would reply so that if someone else ran into this
solution they might find some help.

I understand one build one artifact. I am using Jenkins to initiate multiple builds (one for
each env).  In each build I specify the classifier that I want to use.

This is how I would except a jdk5 vs jdk6 flavor of the jar to work as well. Two builds in
Jenkins, one for jdk5 and one for jdk6.

Sure I could build the jar with the properties then unpack the jar and repack it with the
properties but that is an extra step I don't need. And if a properties file in a jar is an
anti pattern then it is an anti pattern whether I build the properties file into the jar,
or unpack shove it in and repack. 

Again my solution works I was just tying to post the fact that I came up with something in
case someone else is interested. 

I did not fight maven, I got it to work with one line in the Pom file to specify a classifier
for the jar as a variable.

Sent from my iPhone

On Feb 29, 2012, at 6:56 AM, Benson Margulies <> wrote:

> Billy,
> The functionality in Maven is a fact. Whether you or anyone else
> thinks that the design *should* have, or *should*, include your use
> case, it does not. It is the nature of Maven, for better or worse,
> that attempting to use it 'against the grain' generally leads to a
> ramifying collection of painful problems. It is not a simple, passive,
> extensible structure.
> Using profiles and multiple executions of Maven (see the
> maven-invoker-plugin) is the only way I can see to get what you want
> -- roughly. You can then have an additional project that uses the
> build helper to attach them all with classifiers. Just don't expect
> much help if this leads you to additional pain if/when you try to use
> these things as dependencies.
> On Wed, Feb 29, 2012 at 8:44 AM, Billy Newman <> wrote:
>> That still does not help. I do not have a war/ear. I have a jar. I is standalone
and will not run in a container. Jar will not work without the properties file in which it
is backed. There is proprietary info in the different properties files and my company will
not let me include certain properties files to certain places.  It really is coding by properties
as the jar cannot function without the properties, even the unit tests will not run with he
properties file.
>> I still see no reason why I cannot tell maven which properties file to build into
the jar. When that happens why not label the jar for which env it was intended for?
>> Previously I would build the jar when the system was built, so it would need to be
built every time even when there were no code changes. The unit test also ran (which take
a while ) again for no reason since there were no code changes.
>> I read:
>> The classifier allows to distinguish artifacts that were built from the same POM
but differ in their content. It is some optional and arbitrary string that - if present -
is appended to the artifact name just after the version number.
>> As a motivation for this element, consider for example a project that offers an artifact
targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first
artifact could be equipped with the classifier jdk15 and the second one with jdk14such that
clients can choose which one to use.
>> So if I can kick off two builds one for a jdk5 jar and another for a jdk6 jar both
the same version so that the are stored in the same place in the repository but differ by
classifier. Then why not kick off  a couple builds that are meant for different envs whenever
the code changes, bump the version, test the changes and make them all available in the repo?
>> Sent from my iPhone
>> On Feb 29, 2012, at 4:02 AM, Stephen Connolly <>
>>> 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
>>>> 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" <>
>>>>> 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
>>>>>> 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
>>>>>> you in this case.
>>>>>> The maven model is really that you would use different artifactIds
>>>>>> 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:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message