maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
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
<rwheeler@artifact-software.com> 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.

Sure.

>
> 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 http://blog.artifact-software.com/tech
>
> 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<newmanw10@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"<manfred@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message