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 <newman...@gmail.com> 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 <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 >
