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]] Sent: Friday, December 21, 2012 12:37 PM To: [email protected] 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] For additional commands, e-mail: [email protected] __________ 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] For additional commands, e-mail: [email protected]
