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
<rwhee...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
