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
>
&
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.n
> 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
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 attrib
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 ju
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
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.
> de
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
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
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 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
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
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
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
prope
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
artifac
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 fla
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
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-""
cl
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
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
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.con
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 'clas
22 matches
Mail list logo