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:;> > >
