I've seen projects that do this and I don't like it. To my mind "stage" is a runtime concept that your application (or, better yet, the framework your application uses) should adapt itself to, not something which requires different build artifacts.
Justin -----Original Message----- From: Martin Gainty [mailto:[email protected]] Sent: Monday, October 19, 2009 5:45 PM To: [email protected] Subject: RE: Config.jar project dependency ok up until i saw httpa and httpb?..as enjoyable as trying to convert a 10 year old unix makefile with no comments how about using classifiers for staging...dev/test/uat/qa/prod ? Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Mon, 19 Oct 2009 21:30:16 +0200 > Subject: Re: Config.jar project dependency > From: [email protected] > To: [email protected] > > I would say that most of the time when you start thinking about using > classifiers, you should think again. The Javadoc and sources cases are > good examples of when classifiers are the way to go, but I've seen > some very ugly cases where people try to go about the original issue > with bad Maven design by using classifiers. One Maven project has one primary > artifact. Just one. > If you're trying to get two (primary) artifacts out of your project > you're doing things wrong. The primary reason is, as you've stated, > that there is only one pom and therefore only one set of dependencies. > The jdk14 and jdk15 case is, IMO, not a good example of when to use > classifiers, as they could have different dependencies. The dependency > management of Maven is one of the benefits of using Maven, don't break that! > > I believe you're with me on this but I wanted to firmly state this as > there are some very bad examples of classifiers usage. Have a look at > this and > weep: > http://repository.jboss.org/maven2/org/jboss/jbossas/jboss-as-varia/5. > 1.0.GA/ > > /Anders > > On Mon, Oct 19, 2009 at 21:12, Quintin Beukes <[email protected]> wrote: > > > The examples are perfect. Thanks. > > > > > > > I think Todd answered your second question already. One gotcha - > > > there's only one pom, so you can't have different dependencies per > > > classified artifact. This can be worked around with excludes in > > > the downstream project, but if you run into this repeatedly, it > > > suggests that you really need two projects, not two artifacts from > > > the same project differentiated by classifier. > > > > > > > Yeah, though doing this is pretty specialized, so I guess if you > > need different dependencies you most likely need to rethink if your > > building in the most correct way. > > > > Q > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > _________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/171222984/direct/01/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
