Search code examples
blackberrybuildbuild-process

BlackBerry - avoid duplicate package names when using shared library

We write apps for contract - we have many apps out there, and they all use our library. But we have no control over when they are released, that is up to the clients, so they all have different versions of our library (which is always being added to).

I would like to know what the proper way to avoid using the same package name for the library in each project is? I trust this makes sense to the more seasoned BB devs here.

For my distribution builds, I refactor the library to use a unique package name for that project (usually by putting the client's name into the package structure). But this adds time, trouble, and messes with eclipse's svn clients. It seems totally wrong to do it this way (but it works).

There must be a proper way to do this, some tool or script even, since being forced to go down this path each time seems wrong. What is the right way to avoid this problem.

Explanation of Why this is a problem:

  • If you install many apps using the same package structure somewhere in them, then the device overwrites the packages. e.g. If I use com.ric.sdk as my library, then each app that uses my sdk will overwrite whatever version is there.

This is great if we only every upgrade. For us, some issues collide simultaneously, making a problem for us:

  1. We write apps for many different clients, and like to use our common code for each client.
  2. We are a new company, and our sdk is growing. Each app normally adds a few methods to some class or other. So each new app needs the newest sdk. The old apps will still work with the new sdk. The new apps will break with the old sdk.
  3. We do not have release control, so cannot be sure that all apps out there always have the latest sdk.

e.g. we have a radio streaming app which was created 8 months ago. And a video streaming app (unrelated client) from 3 months ago. A vehicle tracking app for this month. If someone installs the tracking app, and then after finds & installs the radio app, the new sdk is overwritten by an old one, and the tracking app breaks because it is not compatible with the old sdk.

(this question deals with the same issues: Do apps downloaded from App World share projects?)

We have learnt the lesson and now refactor the sdk before the final build of each app, to a unique name e.g. radio.ric.sdk or video.ric.sdk.

But this is a horrible process, messes with the svn, wastes time, allows for human error etc - is there a tool that does this for me? I do not believe that we are doing it the right way.

Solution

  • jarjar is the tool you want to use. It allows you to take a jar file and rename all the classes so that they don't conflict with other users of the jar file. In your case, you would add the client's name to the package. The short description of jarjar:

    Jar Jar Links is a utility that makes it easy to repackage Java libraries and embed them into your own distribution. This is useful for two reasons:

    You can easily ship a single jar file with no external dependencies.
    You can avoid problems where your library depends on a specific version of a library, which may conflict with the dependencies of another library.