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 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<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
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
