So this is not true: http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html
bin is used to describe that the artifact is a binary. dev is used to describe that the artifact is for development. prod is used to describe that the artifact is for production. Seems like this is exactly what I would like to use the classifier for. Sent from my iPhone On Feb 29, 2012, at 9:20 AM, Stephen Connolly <[email protected]> wrote: > On 29 February 2012 14:36, Billy Newman <[email protected]> wrote: >> 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. > > Nope... > > you want two different artifactIds as the jdk5 version has different > dependencies than the jdk6 one and different dependencies requires > different GAV > >> >> 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. > > Why not just load the properties file from beside wherever the jar > is.... no need to pack it in at all > >> >> 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 <[email protected]> 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 <[email protected]> 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 >>>> <[email protected]> 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 <[email protected]> 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" <[email protected]> >>>>>> 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: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
