On Wed, Feb 29, 2012 at 9:03 AM, Ron Wheeler <rwhee...@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<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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
