You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Scott Klein <Sc...@goldenhour.com> on 2012/12/21 21:36:48 UTC
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
For additional commands, e-mail: users-help@maven.apache.org
Re: Migration to Maven - Best Practices
Posted by Maven User <ma...@gmail.com>.
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 <rwheeler@artifact-software.com
> 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 <st...@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<st...@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<Sc...@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<us...@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<us...@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<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Migration to Maven - Best Practices
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
>
>
> 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
>>>
>>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Migration to Maven - Best Practices
Posted by Stephen Connolly <st...@gmail.com>.
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
>>
>>
Re: Migration to Maven - Best Practices
Posted by Stephen Connolly <st...@gmail.com>.
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<javascript:;>
> ]
> 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:;><javascript:;>]
> > Sent: Friday, December 21, 2012 12:37 PM
> > To: users@maven.apache.org <javascript:;> <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:;>
> > <javascript:;> For additional commands, e-mail:
> > users-help@maven.apache.org <javascript:;><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:;>
> > <javascript:;> For additional commands, e-mail:
> > users-help@maven.apache.org <javascript:;><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 <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>
RE: Migration to Maven - Best Practices
Posted by Scott Klein <Sc...@goldenhour.com>.
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
Re: Migration to Maven - Best Practices
Posted by Stephen Connolly <st...@gmail.com>.
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:;>
>
>
RE: Migration to Maven - Best Practices
Posted by Scott Klein <Sc...@goldenhour.com>.
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]
Sent: Friday, December 21, 2012 12:37 PM
To: users@maven.apache.org
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
For additional commands, e-mail: users-help@maven.apache.org
__________ 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
For additional commands, e-mail: users-help@maven.apache.org