There are three things that go untouched in this thread. I'm a bit curious as to how "normal" the ant build is at this time, what are the target deployment environments and the frequency at which you would like to move.
As a warning - maven works REALLY well if you're doing normal types of things. The second you try and come off these very strict rails, you find yourself sometimes in a painful limbo between maven and ant. For example, if your ant build is producing ATG "ears" or there are things that you're shelling out to already in ant (or custom tasks), you'll find some really strange things happening within maven. One tip I have here is instead of some atomic conversion from ant->maven, think about using the pom and much of the contents as a consumer of your ant build (if there is weirdness in there). Another thing to contemplate is where you're deploying (your datacenter? some hosted datacenter? the cloud?) and what your targeted "conveyor belt" will be (continous deployment? continuous delivery? continuous integration?). The reason for this is you may opt to release/deploy/etc one webapp and leverage things like the "maven release" plugin/featureset within maven and jenkins. It's REALLY nice to get the all clear from dev and know that clicking "release" will deliver changes from your SCM of choice on through to production. Or better yet, give the keys to the people who "accept" the changes. There is a LOT implied in the statements above (and I truly expect a TL;DR type response :-) - feel free to reach out to me directly and I'm happy to help you even outside of this list. I've done this conversion (ant->mvn) several times and have also done the monolith->modular conversion as well (which can take LONGER and be more painful). Your "common code" module - I think this should live in its own home in source and there should be a ci build that triggers if there are changes (the result of this build is stuff is put into nexus). I think it should be run/treated as a third party type project and it should have releases cut often. I say this to avoid the shifting sands business Stephen so rightfully points out. One thing we do with nexus is have it configured to remove any "released" snapshots. For example, if you have 1.0-SNAPSHOT and release it, you produce a 1.0 artifact. Nexus will then go and remove that snapshot from the repository. Any builds relying on that will fail and you'll catch the problem early. One final thought - If you go from a monolithic build (one source repository build resulting in many unrelated artifacts) to a highly modular one, you can't freak out if builds break. In a very modular build world, where the builds take one to two minutes (max in my case - with tests), it's ok to see builds fail - because it only takes moments to fix. In the case of a much longer monolithic build (say, 5 to 10 min), then, yeah, I'd start collecting fingers, implement a policy of "don't check in or push if the build is broken", etc. HTH On Mon, Dec 24, 2012 at 5:04 PM, Ron Wheeler <[email protected] > wrote: > Stephen is much more of an expert than I am but I can tell you how we > build. > > His article on SNAPSHOTs is very good reading and describes the use of > SNAPSHOTS very well. > We are a small team with a lot of modules. > I let programmers release SNAPSHOTs when they were prepared to warranty > the performance. > Our SNAPSHOTS are released when they are ready to be used by another > programmer to testing their own work. > The SNAPSHOT stram will usually have increasing functionality but the > author should be able to describe what it does and does not do. > > We started by having all modules with the same version but as the number > increased to 70 and the system became more stable, we did not see the value > in releasing new versions of code that had not changed. > > We do not use a CI server but are great believers in Nexus or some other > Maven Repo. We started without one and it was a PITA. > > Ron > > > On 22/12/2012 5:33 AM, Stephen Connolly wrote: > >> 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<http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html> >> >> >> On 22 December 2012 08:17, Stephen Connolly <stephen.alan.connolly@gmail. >> **com <[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:stephen.alan.connolly@**gmail.com<[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:Scott.Klein@**goldenhour.com<[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: >>>>> users-unsubscribe@maven.**apache.org<[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: >>>>> users-unsubscribe@maven.**apache.org<[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: >>>> users-unsubscribe@maven.**apache.org<[email protected]> >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
