Since I mentioned deploying snapshots... I thought I would clarify my thinking in that regard as a blog post!
http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html On 22 December 2012 08:17, Stephen Connolly <[email protected] > wrote: > 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]] >> 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:;>] >> > Sent: Friday, December 21, 2012 12:37 PM >> > To: [email protected] <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:;> For additional commands, e-mail: >> > [email protected]<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:;> For additional commands, e-mail: >> > [email protected]<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] >> For additional commands, e-mail: [email protected] >> >>
