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 < > [email protected]> wrote: > > > On 29 February 2012 14:36, Billy Newman <[email protected]> wrote: > >> I have a solution that already works, is what I am really trying to say. > >> > >> Rather than keep it to myself I thought I would reply so that if > someone else ran into this solution they might find some help. > >> > >> I understand one build one artifact. I am using Jenkins to initiate > multiple builds (one for each env). In each build I specify the classifier > that I want to use. > >> > >> This is how I would except a jdk5 vs jdk6 flavor of the jar to work as > well. Two builds in Jenkins, one for jdk5 and one for jdk6. > > > > Nope... > > > > you want two different artifactIds as the jdk5 version has different > > dependencies than the jdk6 one and different dependencies requires > > different GAV > > > >> > >> Sure I could build the jar with the properties then unpack the jar and > repack it with the properties but that is an extra step I don't need. And > if a properties file in a jar is an anti pattern then it is an anti pattern > whether I build the properties file into the jar, or unpack shove it in and > repack. > > > > Why not just load the properties file from beside wherever the jar > > is.... no need to pack it in at all > > > >> > >> Again my solution works I was just tying to post the fact that I came > up with something in case someone else is interested. > >> > >> I did not fight maven, I got it to work with one line in the Pom file > to specify a classifier for the jar as a variable. > >> > >> > >> Sent from my iPhone > >> > >> On Feb 29, 2012, at 6:56 AM, Benson Margulies <[email protected]> > wrote: > >> > >>> Billy, > >>> > >>> The functionality in Maven is a fact. Whether you or anyone else > >>> thinks that the design *should* have, or *should*, include your use > >>> case, it does not. It is the nature of Maven, for better or worse, > >>> that attempting to use it 'against the grain' generally leads to a > >>> ramifying collection of painful problems. It is not a simple, passive, > >>> extensible structure. > >>> > >>> Using profiles and multiple executions of Maven (see the > >>> maven-invoker-plugin) is the only way I can see to get what you want > >>> -- roughly. You can then have an additional project that uses the > >>> build helper to attach them all with classifiers. Just don't expect > >>> much help if this leads you to additional pain if/when you try to use > >>> these things as dependencies. > >>> > >>> > >>> > >>> On Wed, Feb 29, 2012 at 8:44 AM, Billy Newman <[email protected]> > wrote: > >>>> That still does not help. I do not have a war/ear. I have a jar. I is > standalone and will not run in a container. Jar will not work without the > properties file in which it is backed. There is proprietary info in the > different properties files and my company will not let me include certain > properties files to certain places. It really is coding by properties as > the jar cannot function without the properties, even the unit tests will > not run with he properties file. > >>>> > >>>> I still see no reason why I cannot tell maven which properties file > to build into the jar. When that happens why not label the jar for which > env it was intended for? > >>>> > >>>> Previously I would build the jar when the system was built, so it > would need to be built every time even when there were no code changes. The > unit test also ran (which take a while ) again for no reason since there > were no code changes. > >>>> > >>>> I read: > >>>> The classifier allows to distinguish artifacts that were built from > the same POM but differ in their content. It is some optional and arbitrary > string that - if present - is appended to the artifact name just after the > version number. > >>>> As a motivation for this element, consider for example a project that > offers an artifact targeting JRE 1.5 but at the same time also an artifact > that still supports JRE 1.4. The first artifact could be equipped with the > classifier jdk15 and the second one with jdk14such that clients
