Re: How to deploy with 'classifier'

2012-03-06 Thread Anders Hammar
One problem with multiple artifacts using classifier is that they will
share the same pom, which makes them all having the same dependency set.
This most often not desirable.

/Anders (mobile)
Den 7 mar 2012 03.05 skrev "sethcall" :

> I've read this entire thread, and I'm not understanding the point about
> 'this
> is just now how it should be done' vs Billy's 'this is useful and it works'
>
> If using a classifier in the way Billy has is frowned upon... ok... I'll
> accept that for a second... but can anyone tell me a* concrete technical
> reason* why it will get me into trouble using it this way?
>
> I have another use-case for classifiers--Ivy allows the idea of multiple
> artifacts for one ivy.xml file.  But Maven does not.  However,  I limit
> myself in using Ivy to only create same-named artifacts with classifiers in
> a versioning scheme compatible with Maven, and if I need to create multiple
> artifacts from a single pom using classifiers, then I've found a way to use
> both Ivy and Maven in a lowest-common denominator way (important for me at
> the moment because our team is part Ivy and part Maven).
>
> So my point is... why can't classifiers just be 'arbitrary ways to further
> describe a single artifact'?  Can we frown upon any other interpretation?
> Can we move the maven community that way now? :)
>
> Thanks,
> Seth
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/How-to-deploy-with-classifier-tp5523009p5542945.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


Re: How to deploy with 'classifier'

2012-03-06 Thread sethcall
I've read this entire thread, and I'm not understanding the point about 'this
is just now how it should be done' vs Billy's 'this is useful and it works' 

If using a classifier in the way Billy has is frowned upon... ok... I'll
accept that for a second... but can anyone tell me a* concrete technical
reason* why it will get me into trouble using it this way?

I have another use-case for classifiers--Ivy allows the idea of multiple
artifacts for one ivy.xml file.  But Maven does not.  However,  I limit
myself in using Ivy to only create same-named artifacts with classifiers in
a versioning scheme compatible with Maven, and if I need to create multiple
artifacts from a single pom using classifiers, then I've found a way to use
both Ivy and Maven in a lowest-common denominator way (important for me at
the moment because our team is part Ivy and part Maven).

So my point is... why can't classifiers just be 'arbitrary ways to further
describe a single artifact'?  Can we frown upon any other interpretation? 
Can we move the maven community that way now? :)

Thanks,
Seth

--
View this message in context: 
http://maven.40175.n5.nabble.com/How-to-deploy-with-classifier-tp5523009p5542945.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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



Re: How to deploy with 'classifier'

2012-02-29 Thread Wayne Fay
> The point is that the official documentation implicitly blesses described
> usages. That is, when the official documentation describes a design or

This documentation should be changed to reflect the current thinking
on classifiers. This has changed through the years. Originally the
dev/prod use was more widely accepted but through the years that has
fallen out of favor.

Wayne

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



Re: How to deploy with 'classifier'

2012-02-29 Thread Benson Margulies
On Wed, Feb 29, 2012 at 9:03 AM, Ron Wheeler
 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  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.
>>>
>>> ${env}
>>>
>>> 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"
>>>  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

 ---

Re: How to deploy with 'classifier'

2012-02-29 Thread Billy Newman
Curtis

I agree completely. I was looking for a solution to my problem. I discovered 
maven documentation that the classifier  feature is intended to be used for my 
situation. In fact the example given in the docs is exactly how I want to use 
the feature. 

It's not a matter of doing something just cause I can. It's a matter if the 
docs providing me with a solution. 

If the feeling is that strongly that this feature should not be used to have 
different flavors of jars like dev and ops then remove that feature and/ or 
change the docs. 

Again I did not come up with this pattern on my own. I learned about it on the 
maven site. 

Sent from my iPhone

On Feb 29, 2012, at 11:04 AM, Curtis Rueden  wrote:

> Hi Stephen,
> 
> Just because you *can* do something doesn't mean you *should*
>> 
> 
> The point is that the official documentation implicitly blesses described
> usages. That is, when the official documentation describes a design or
> usage pattern, the implication is that the feature in question was intended
> to be used in the described way.
> 
> So, if classifiers were not meant to be used that way—or even if such usage
> is simply discouraged for whatever reason—wouldn't it be best to change the
> documentation to reflect that? It is great that Ron is adapting your
> helpful explanation into a blog entry, but wouldn't it be best as a writeup
> or blurb on the official Maven site?
> 
> Regards,
> Curtis
> 
> 
> On Wed, Feb 29, 2012 at 11:54 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> 
>> Just because you *can* do something doesn't mean you *should*
>> 
>> On Wednesday, 29 February 2012, Billy Newman wrote:
>> 
>>> 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 <
>>> stephen.alan.conno...@gmail.com> wrote:
>>> 
 On 29 February 2012 14:36, Billy Newman  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 
>>> 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 
>>> 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 

Re: How to deploy with 'classifier'

2012-02-29 Thread Curtis Rueden
Hi Stephen,

Just because you *can* do something doesn't mean you *should*
>

The point is that the official documentation implicitly blesses described
usages. That is, when the official documentation describes a design or
usage pattern, the implication is that the feature in question was intended
to be used in the described way.

So, if classifiers were not meant to be used that way—or even if such usage
is simply discouraged for whatever reason—wouldn't it be best to change the
documentation to reflect that? It is great that Ron is adapting your
helpful explanation into a blog entry, but wouldn't it be best as a writeup
or blurb on the official Maven site?

Regards,
Curtis


On Wed, Feb 29, 2012 at 11:54 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Just because you *can* do something doesn't mean you *should*
>
> On Wednesday, 29 February 2012, Billy Newman wrote:
>
> > 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 <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On 29 February 2012 14:36, Billy Newman  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 
> > 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 
> > 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
>

Re: How to deploy with 'classifier'

2012-02-29 Thread Stephen Connolly
Just because you *can* do something doesn't mean you *should*

On Wednesday, 29 February 2012, Billy Newman wrote:

> 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 <
> stephen.alan.conno...@gmail.com> wrote:
>
> > On 29 February 2012 14:36, Billy Newman  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 
> 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 
> 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


Re: How to deploy with 'classifier'

2012-02-29 Thread Billy Newman
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  
wrote:

> On 29 February 2012 14:36, Billy Newman  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  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  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 
  wrote:
 
> Argh
> 
> You're doin

Re: How to deploy with 'classifier'

2012-02-29 Thread Stephen Connolly
No problem:

Stephen Connolly
Hat #1: Apache Maven Project Management Committee
Hat #2: CloudBees Elite Developer & Architect

On 29 February 2012 14:03, Ron Wheeler  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.
>
> 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  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.
>>>
>>> ${env}
>>>
>>> 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"
>>>  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 plu

Re: How to deploy with 'classifier'

2012-02-29 Thread Stephen Connolly
On 29 February 2012 14:36, Billy Newman  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  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  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 
>>>  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 con

Re: How to deploy with 'classifier'

2012-02-29 Thread Billy Newman
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  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  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 
>>  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.
>>> 
>>> 

Re: How to deploy with 'classifier'

2012-02-29 Thread Ron Wheeler

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  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.

${env}

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"  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-

Re: How to deploy with 'classifier'

2012-02-29 Thread Benson Margulies
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  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 
>  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  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 ja

Re: How to deploy with 'classifier'

2012-02-29 Thread Billy Newman
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  
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  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.
>> 
>> ${env}
>> 
>> 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"  wrote:
>> 
>>> On Tue, February 28, 2012 2:13 pm, Benson Margulies wrote:
 Let me try to arrange the explanation here in good order.
 
 Classifiers

Re: How to deploy with 'classifier'

2012-02-29 Thread Stephen Connolly
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  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.
>
> ${env}
>
> 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"  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



Re: How to deploy with 'classifier'

2012-02-28 Thread Billy Newman
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. 

${env}

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"  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



Re: How to deploy with 'classifier'

2012-02-28 Thread Manfred Moser
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



Re: How to deploy with 'classifier'

2012-02-28 Thread Benson Margulies
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.

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



RE: How to deploy with 'classifier'

2012-02-28 Thread Matt Walsh
I can understand needing to do this. For reasons I won't get into, I had
to do something similar in order to split a huge jar file. 

The compile phase compiled all the classes I needed, so I used the
package phase to create 2 jars from the same sources by overriding the
default-jar execution and creating a second execution to create the
second, classified, jar, as shown below. Note the id=default-jar in the
first execution and the classifer=someClassifier in the second one.

Both get installed/deployed by default.

I suppose you could split the default-compile in a similar fashion if
that's where you're headed.


  maven-jar-plugin


  default-jar
  package
  
jar
  
  

  


  classified-jar
  package
  
jar


someClassifier

  

  



HTH,
Matt


> -Original Message-
> From: Ansgar Konermann [mailto:ansgar.konerm...@googlemail.com]
> Sent: Tuesday, February 28, 2012 2:09 PM
> To: Maven Users List
> Subject: Re: How to deploy with 'classifier'
> 
> Am 28.02.2012 22:02 schrieb "Billy Newman" :
> >
> > So what is the recommended way to create different flavors of jars
> with a
> > 'classifier'?
> >
> > Also I don't see how I am fighting maven I am sure this is possible
> as
> > people build a 'sources' and 'javadoc' classifier within one module.
> 
> True. However, the main artifact has no classifier, even in these
> cases.
> Sources and javadoc are so-called "attached" artifacts, which derive
> their
> coordinates from those of the main artifact, plus the classifier.
> 
> Pick a different artifactId for your different flavours.
> 
> Best
> 
> Ansgar
> 
> >
> >
> > On Tue, Feb 28, 2012 at 1:48 PM, Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > You are fighting maven. One artifact one module
> > >
> > > Sent from my iPhone
> > >
> > > On 28 Feb 2012, at 19:40, Billy Newman 
wrote:
> > >
> > > > I have a pretty simple pom file setup to build a jar.  I can
> deploy
> to my
> > > > internal repository just fine.  However I want to build
different
> flavors
> > > > of my jar and use the 'classifier' tag  and deploy.
> > > >
> > > > However I can specify a 'classifier' in my pom file (with the
> > > > group/artifact id and version), and I cannot seem to find how to
> specifiy
> > > > the 'classifier' in the maven-deploy-plugin either.
> > > >
> > > > Since I am building with maven I do not want to use the deploy-
> file
> > > plugin.
> > > >
> > > > What am I missing?
> > > >
> > > > Thanks in advance.
> > >
> > >
---
> --
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >

__
This message, including any attachments, is confidential and contains 
information intended only for the person(s) named above. Any other 
distribution, copying or disclosure is strictly prohibited. If you are not the 
intended recipient or have received this message in error, please notify us 
immediately by reply email and permanently delete the original transmission 
from all of your systems and hard drives, including any attachments, without 
making a copy.

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



Re: How to deploy with 'classifier'

2012-02-28 Thread Ansgar Konermann
Am 28.02.2012 22:02 schrieb "Billy Newman" :
>
> So what is the recommended way to create different flavors of jars with a
> 'classifier'?
>
> Also I don't see how I am fighting maven I am sure this is possible as
> people build a 'sources' and 'javadoc' classifier within one module.

True. However, the main artifact has no classifier, even in these cases.
Sources and javadoc are so-called "attached" artifacts, which derive their
coordinates from those of the main artifact, plus the classifier.

Pick a different artifactId for your different flavours.

Best

Ansgar

>
>
> On Tue, Feb 28, 2012 at 1:48 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > You are fighting maven. One artifact one module
> >
> > Sent from my iPhone
> >
> > On 28 Feb 2012, at 19:40, Billy Newman  wrote:
> >
> > > I have a pretty simple pom file setup to build a jar.  I can deploy
to my
> > > internal repository just fine.  However I want to build different
flavors
> > > of my jar and use the 'classifier' tag  and deploy.
> > >
> > > However I can specify a 'classifier' in my pom file (with the
> > > group/artifact id and version), and I cannot seem to find how to
specifiy
> > > the 'classifier' in the maven-deploy-plugin either.
> > >
> > > Since I am building with maven I do not want to use the deploy-file
> > plugin.
> > >
> > > What am I missing?
> > >
> > > Thanks in advance.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >


Re: How to deploy with 'classifier'

2012-02-28 Thread Billy Newman
So what is the recommended way to create different flavors of jars with a
'classifier'?

Also I don't see how I am fighting maven I am sure this is possible as
people build a 'sources' and 'javadoc' classifier within one module.


On Tue, Feb 28, 2012 at 1:48 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> You are fighting maven. One artifact one module
>
> Sent from my iPhone
>
> On 28 Feb 2012, at 19:40, Billy Newman  wrote:
>
> > I have a pretty simple pom file setup to build a jar.  I can deploy to my
> > internal repository just fine.  However I want to build different flavors
> > of my jar and use the 'classifier' tag  and deploy.
> >
> > However I can specify a 'classifier' in my pom file (with the
> > group/artifact id and version), and I cannot seem to find how to specifiy
> > the 'classifier' in the maven-deploy-plugin either.
> >
> > Since I am building with maven I do not want to use the deploy-file
> plugin.
> >
> > What am I missing?
> >
> > Thanks in advance.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


Re: How to deploy with 'classifier'

2012-02-28 Thread Stephen Connolly
You are fighting maven. One artifact one module

Sent from my iPhone

On 28 Feb 2012, at 19:40, Billy Newman  wrote:

> I have a pretty simple pom file setup to build a jar.  I can deploy to my
> internal repository just fine.  However I want to build different flavors
> of my jar and use the 'classifier' tag  and deploy.
> 
> However I can specify a 'classifier' in my pom file (with the
> group/artifact id and version), and I cannot seem to find how to specifiy
> the 'classifier' in the maven-deploy-plugin either.
> 
> Since I am building with maven I do not want to use the deploy-file plugin.
> 
> What am I missing?
> 
> Thanks in advance.

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