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 <bimargul...@gmail.com> 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 <newman...@gmail.com> 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
>> <stephen.alan.conno...@gmail.com> 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
>>>
>
> ---------------------------------------------------------------------
> 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
