maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Migration to Maven - Best Practices
Date Fri, 21 Dec 2012 21:24:11 GMT
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 <javascript:;>]
> Sent: Friday, December 21, 2012 12:37 PM
> To: users@maven.apache.org <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 <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<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 <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message