Well those answers point to having one über project in SCM that gets released in one go.
All three components: A, B and Common will have the same version number. If you have different teams working on A and B then you would probably set up a CI job that deploys SNAPSHOTs on a nightly basis so that a dev can just check out A and work away... I'd recommend a CI job to cut the release in that case ( good practice anyway, but if most devs don't check out the whole über project and only check out their subset (if using SVN like SCM... If you use GIT it will all be in the one GIT repo as you are releasing as one process) they will benefit from a CI job for releasing) Nothing wrong with the other way, just will involve more formalism between releasing A, B, and Common and force a different QA process - Stephen On Saturday, 22 December 2012, Scott Klein wrote: > Thanks for the questions. Also, thanks for writing all those articles on > proper use - very enlightening. > > > Do you always deploy A and B together? > > No, but we can change this. I think I actually prefer this answer to be > Yes. In light of the following: > > We currently can deploy A, B or Common individually - each one has its own > ant script. We just have to be cautious about Common "deploys" because > changes in it can break stuff in non-updated A and B products. > MethodNotFoundExceptions for example, if a method signature is changed in > Common. > > Just a side note, our app server each have their own prop files which > define them as dev, test or prod - DB URLs, for example. So after we > "deploy" to dev, a "deploy" to test is just a script which pushes the > artifacts from dev up to test. Same for production. > > So basically we package everything one time for the dev server and then > just promote those artifacts up the line to the other servers. > > > Do you always release A and B together? > > Yes. We tag (or branch) it all together. Then we manually update our > version numbers for each product in our code. > > > > -----Original Message----- > From: Stephen Connolly [mailto:[email protected]<javascript:;> > ] > Sent: Friday, December 21, 2012 11:24 AM > To: Maven Users List > Subject: Re: Migration to Maven - Best Practices > > Do you always deploy A and B together? > > Do you always release A and B together? > > > > On Friday, 21 December 2012, Scott Klein wrote: > > > crap, that came out all horrible looking, let me try to fix that > > section up ... > > > > <snip> > > > > Right now we have a number of individual Eclipse projects and we build > > everything with Ant. > > > > * A-Client - Client side Product A project > > > > * A-Server - Server side Product A project > > > > * A-Common - Shared Code for Product A > > > > > > * B-Client - Client side Product B project > > > > * B-Server - Server side Product B project > > > > * B-Common - Shared Code for Product B > > > > > > * ALL-Common - used by all products (this is mostly hibernate stuff, > > hbms, DAOs, etc) > > > > <snip> > > > > Sorry about that...also fixed it below (I hope) if you want to read it > > in context > > > > -----Original Message----- > > From: Scott Klein [mailto:[email protected] > > <javascript:;><javascript:;>] > > Sent: Friday, December 21, 2012 12:37 PM > > To: [email protected] <javascript:;> <javascript:;> > > Subject: Migration to Maven - Best Practices > > > > I am working on converting a number of products over to Maven and > > after reading quite a bit I wanted to get some advice on best > > practices - especially after reading the thread "Recursive Maven > considered harmful" > > and about the "clean install" problem (which is where I ended up after > > my first attempt). I realize that I know just enough about Maven, > > learned over the past few weeks, to be dangerous. Looking for some > > guidance from people who have much more experience than anyone in my > > organization (not a high > > bar!) > > > > Right now we have a number of individual Eclipse projects and we build > > everything with Ant. > > > > * A-Client - Client side Product A project > > > > * A-Server - Server side Product A project > > > > * A-Common - Shared Code for Product A > > > > > > * B-Client - Client side Product B project > > > > * B-Server - Server side Product B project > > > > * B-Common - Shared Code for Product B > > > > > > * ALL-Common - used by all products (this is mostly hibernate stuff, > > hbms, DAOs, etc) > > > > > > As an added caveat our "ALL-Common" code is *not* released with each > > individual product, it is a "provided" jar file and we make it > > available to both client and server via our /tomcat/lib directory -- > > as we do a lot of our dependencies, like log4j, guava, joda, etc -- to > > ensure everyone is working with the latest and greatest and proper > > versions. Basically, part of our deploy process now is to create that > > jar and shove it up to our tomcat lib directory during a release. This > > was particularly helpful to keep us from having to release every > > product anytime our hibernate code or db schema changed. > > > > I believe that my first concern is what to do with that "ALL-Common" > code: > > > > 1. Do we treat this like a dependency that we control? And then have > > each product be its own multi-module project (one each for A and B) > > -> What potential pitfalls do we run into here? Shouldn't all products > > compile against the latest to ensure there are no issues? Is this just > > something we would notice in our development environment once the new > > ALL-Common code was deployed - rather than checked into SCM? > > > > OR > > > > 2. Do we bundle all of our stuff into a single, monstrous multi-module > > project? I see something like this: > > > > + All Products > > - + A > > - - Client > > - - Server > > - - Common > > - + B > > - - Client > > - - Server > > - - Common > > - + Common > > - - Common > > > > -> This might *force* us to build everything at once, share a version > > among *everything* and when we release everything goes at once. This > > would ensure that everything gets compiled and tested against the > > latest common code during a deploy. It would also, it appears to me, > > allow us to see issues after a check-in rather than a deploy of the > Common code. > > > > > > I am looking for a best practices and what works best without having > > to do "inappropriate" things with Maven. I have read most of the PDFs, > > but any URLs to articles, blogs or open source projects with similar > > constraints would be welcome. I have to believe this is not an > > un-common scenario, so any helpful input on any aspect of this is more > than welcome! > > > > > > Thanks in advance, > > scott > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 7825 (20121221) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected]<javascript:;> > > <javascript:;> For additional commands, e-mail: > > [email protected] <javascript:;><javascript:;> > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 7825 (20121221) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > > signature database 7825 (20121221) __________ > > > > The message was checked by ESET NOD32 Antivirus. > > > > http://www.eset.com > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected]<javascript:;> > > <javascript:;> For additional commands, e-mail: > > [email protected] <javascript:;><javascript:;> > > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7826 (20121221) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 7826 (20121221) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] <javascript:;> > For additional commands, e-mail: [email protected]<javascript:;> > >
