7

Over the years I've created a bunch of Java utility and helper libraries which I just attach to new projects. Then, when I deliver code to my clients, I send all the code except for the libraries themselves (not JARs but source code files).

A client complained that he could not compile the project as some libraries were missing. I tried explaining him about my own libraries, but he was not satisfied.

How do you handle such situations? I am still apporting changes to these libraries often and I cannot compile JARs each time I start working on some new project. How to overcome this issue - not to share private libraries (personal intellectual property) and have happy clients?

Francesco
  • 1,416
  • 14
  • 22
deviDave
  • 2,953

5 Answers5

23

If the contract expects source code to be delivered, then the source code you give them should compile.

Not giving them the libraries to do this is ridiculous.

If the code in your libraries is generic helper type code, then there is nothing wrong with giving them the binaries and some license agreement with them.

If the libraries contain something specific to how the system is built then the customer will be within their right to expect to receive that code as well. They may need to modify it at some point for example.

ozz
  • 8,352
17

First, this is mainly about the contract you have with the client. If you have a contract which includes delivering of the source code, your client can expect source code they can compile by himself. If you refuse to do this, you break the contract - and it does not matter if the missing source in lib A or lib B or lib "Utility". From the client's point of view, there is no difference between those parts.

If you have specificially excluded some libs in your contract (and your client inattentively signed that), then you may rightfully refuse to deliver your source for that libs, but don't expect to keep the client in the future.

If you want to avoid that situation in the future, separate your utility library clearly in your contract and try to sell / license it to your customers as a closed-source-product, together with the sources of the main product your are creating for them. That will imply proper versioning and configuration management of your utitlity lib, of course.

Doc Brown
  • 218,378
3

You probably have to version your proprietary library and make (your own internal) releases. Then when you start a new project, you just use your latest released library in that project, and upgrade to a new version whenever needed.

Then you can send the source to your client, including the jar of your library in the version that you have tested the project with.

Bjarke Freund-Hansen
  • 1,186
2

If client is indeed concerned only about code being compilable, consider making and passing them "stubs" that don't do work but implement interfaces needed for code to compile:

public class MyClass {
    public void myMethod() {
        throw unsupported();
    }
    private UnsupportedOperationException unsupported() {
        return new UnsupportedOperationException(
                "stub code intended to use only in compilation");
    }
}
gnat
  • 20,543
  • 29
  • 115
  • 306
1

To add to what bjarkef wrote, you should have an automated build process, so that your libraries are built automatically.

You should label the stable releases of your libraries source code and binaries (jars).

When you distribute a product based on your libraries or on 3rd party libraries you should include the binaries (jars) of all the libraries you tested it against within your release.

There are certain open source projects that do not distribute their 3rd party dependencies along with their distribution, however, this is a very bad practice.

Your client is correct to insist on receiving products that are complete and not to start looking for the correct version of all your dependencies.

Danny Varod
  • 1,158