views:

71

answers:

1

I am trying to figure out what is the best way to handle dependencies in app servers. We are considering maven to build the apps, but we found a problem. It appears when we need to update a proprietary shared library that doesn't have version number.This happens once a month and we are using Websphere shared library function in the following way:

  • For each shared library in Websphere we create an alias without version. For example: db-component-1.2.1 receives the alias db-component. During the first deployment, we associate the app with the required libraries using the aliases. As we ignore the version, all apps must use the same version, creating some restrictions. But when we need to upgrade a shared library, we just upload the new library in WS and then, all apps uses the updated version.

We have more than 70 apps that rely on proprietary shared libraries. These libraries change constantly, and this solution makes the management easier. But it seems a bit odd that the dependencies are changed outside the application's build process. The dependency control isn't reliable anymore, because the info in app's POM may be false. In addition, all apps must use the same versions.

I think that a better solution may exist.

We've considered another model. Include the dependencies in every war. This allows us to use different versions of libraries in each application without restriction. But there is one problem: when a change is made in a proprietary shared library, we need to rebuild and redeploy all apps.

I have thought about our proprietary shared library being so instable or using a solution that mixes both ideas, but I am not sure how to solve this problem. OSGI looks like a better way to handle dependencies, but we would have the same problem upgrading many apps.

Should we use WS's shared library function? Is there a better way to solve this problem? Tips are highly appreciated.

Thanks

+1  A: 

I'm not sure if I fully understand what you are asking, I first thought that you were unsure how to manage dependencies which are not available in a versioned manner, if so:

You already mentioned OSGi, you may want to consider running your own maven repository using Nexus which would allow you to version unversioned jars yourself.

Without wishing to state the obvious, you can't use a specific version of something that doesn't have versions...

But on re-reading your question it sounds like you may be asking whether its better to have explicit dependencies for each of your application or some shared set of dependencies which are updated on the fly, pushing changes to all of your apps. I would say the following:

  • You want repeatable builds, which means you need to know when you build an application which version of dependent libraries it used
  • You want to ensure that all projects pick up latest version of dependencies when next built

You can use the Maven versions plugin to manage this kind of thing, we have a parent pom defining versions of all libs in the dependencyManagement section and run a script against this every 5 minutes to look for updated dependencies. Whenever the parent pom changes all child pom's are updated and checked into source control, which means that once a new shared lib is released, we will try and build and then unit test all our apps.

Jon Freedman
I am really looking for advice about "whether its better to have explicit dependencies or some shared set of dependencies". Your suggestion gave me some ideas. I will check this plugin. Having repeatable builds is very important, but it generates operational problems to deploy 60 apps. Do you have a similar scenario? Is this how you handle it?
David Reis
We've always explicitly versioned all our dependencies, just with the maven/nexus/versions plugin combo we never need to worry about checking all our individual projects for breaking changes when we updated shared code. Any issues that require a specific non-current version are easy to identify (only happened once in ~6months)
Jon Freedman