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:[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:[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:;>
__________ 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: [email protected]
For additional commands, e-mail: [email protected]
