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 <[email protected]> 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 < > [email protected]> 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 < >>> [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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
