maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
Subject Re: Dependency version management
Date Mon, 28 Feb 2011 20:04:06 GMT
On 28/02/2011 2:39 PM, Phillip Hellewell wrote:
> Interesting ideas, thanks.  By "aggregation jars" I assume you mean
> like intermediate components with no actual code but that serve to
> manage versions.  I think that is a neat idea.
As much I Iove being associated with a neat idea, I have to point out 
that we actually build jars with these 8 (6 third party code + 2 ours) 
POMs that we deploy as shareable libraries in Tomcat.
The 34 war modules have these as "provided" dependencies which means 
that our war files are very small and only contain our code and 
resources (images can add a lot to a WAR).

We have a lot of wars that are less than 50kb even with Spring, 
Hibernate, CXF, JSF

This is really nice when dealing with something CXF which adds a huge 
amount of bytes to a WAR if it is not "provided".
The total amount of bytes of JARS from our aggregated POMS is about 40MB 
in the Tomcat lib
A couple of these JARs are our own utilities.

I am not sure where this fits on the "neat" scale but it helps keep our 
dependencies under control and really speeds up builds and deploys.

Ron

> Phillip
>
> On Mon, Feb 28, 2011 at 10:23 AM, Ron Wheeler
> <rwheeler@artifact-software.com>  wrote:
>> Our move to aggregation jars was our solution of this problem.
>> We wanted central control over versions without a lot places to manage
>> version numbers.
>> For each application release, we decide what third versions of third party
>> libraries will be used.
>> If any of the libraries need changing we create the updated versions.
>>
>> We used to create new versions of all of the libraries but we stopped since
>> it was a lot of work for nothing.
>> The cost is that version 1.11.2 of the application depends on 1.9.1 of the
>> CXF webservice libraries.
>>
>> We maintain a simple spreadsheet of components so that everyone knows what
>> they are supposed call on as versions of the 5 or so dependencies that gives
>> them their 60+ libraries required to build our application.
>>
>> We generally do not make or use SNAPSHOTs for these libraries so that
>> simplifies the process.
>>
>> I hope that this helps.
>>
>> Ron
>>
>> On 28/02/2011 11:49 AM, Phillip Hellewell wrote:
>>> I'm thinking about moving all our version management into the parent
>>> pom in a dependencyManagement section, but I'm trying to figure out if
>>> it will really make things easier or not.
>>>
>>> Of course each version number would only be in one place instead of N
>>> places, where N is the avg # of reverse dependencies.  So that is
>>> good.  But when changing the version # of a component, you still have
>>> to update N places, to update them to the latest parent.  That is,
>>> unless you are using a snapshot for the parent, but is that a
>>> normal/recommended practice?
>>>
>>> The problem I see with using a snapshot for the parent is it doesn't
>>> allow you to make changes in a safe way.  I could update the version #
>>> of a lower component, and then a much higher component could build
>>> against that before all the middle components are built/deployed.
>>> This may not be a problem for Java or C#, but for C/C++ with headers
>>> and static libraries, it is a recipe for disaster.  We're talking
>>> about things like inexplicable run-time crashes.
>>>
>>> By having version management in each pom itself, I can safely make a
>>> change to a lower component by upping the version # of its reverse
>>> dependencies at the same time I update them to use the new version of
>>> the lower component, and then follow that pattern as I go all the way
>>> up the chain of dependencies.
>>>
>>> Of course a continuous integration tool could be used to build all the
>>> reverse dependencies up the chain for you, and such a tool is much
>>> easier to set up when it doesn't have to worry about changing version
>>> #s in the pom, but that still leaves open a possible race condition.
>>> It could be only halfway through building/deploying all the components
>>> when a developer tries to build a high level component and runs into
>>> the problem I described.
>>>
>>> Some of our components take a long time to build, so there is a very
>>> real risk of this race condition.  So I don't know if it is worth it.
>>> But maybe it is especially if it saves us time of building things
>>> manually (which we have to do now because I haven't found a tool that
>>> can kick off builds of reverse dependencies, and also up the version
>>> numbers along the way.)
>>>
>>> Phillip
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message