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 Sat, 22 Dec 2012 10:33:35 GMT
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 <stephen.alan.connolly@gmail.com
> 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]
>> 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 <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:;>
>> >
>> >
>>
>>
>> __________ 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
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>

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