views:

206

answers:

3

I want to give credit to all open source libraries we use in our (commercial) application. I thought of showing a HTML page in our about dialog. Our build process uses ant and the third party libs are committed in svn.

What do you think is the best way of generating the HTML-Page?

  • Hard code the HTML-Page?
  • Switch dependency-management to apache-ivy and write some ant task to generate the html
  • Use maven-ant-tasks and write some ant task to generate the HTML
  • Use maven only to handle the dependencies and the HTML once, download them and commit them. The rest is done by the unchanged ant-scripts
  • Switch to maven2 (Hey boss, I want to switch to maven, in 1 month the build maybe work again...)
  • ...

What elements should the about-dialog show?

  • Library name
  • Version
  • License
  • Author
  • Homepage
  • Changes made with link to source archive
  • ...

Is there some best-practise-advice? Some good examples (applications having a nice about-dialog showing the dependencies)?

+3  A: 

Ant task seems to be the best way. We do a similar thing in one of our projects. All the open source libraries are present in a specified folder. An Ant task reads the manifest of these libraries, versions and so on and generates an HTML, copies into another specified folder from where it is picked up by the web container.

Nikhil Kashyap
And what do you do if the library jar's Manifest does not contain some information?
Tobias Schulte
+2  A: 

Generating the page with each build would be wasteful if the libraries are not going to change often. Library versions may change, but the actual libraries don't. Easier to just create a HTML page would be the easiest way out, but that's one more maintenance head ache. Generate it once and include it with the package. The script can always be run again in case some changes are being made to the libraries (updating versions, adding new libraries).

Arvind
+3  A: 

There are two different things you need to consider.

First, you may need to identify the licenses of the third-party code. This is often down with a THIRDPARTYLICENSE file. Sun Microsystems does this a lot. Look in the install directory for OpenOffice.org, for example. There are examples of .txt and .html versions of such files around.

Secondly, you may want to identify your dependencies in the About box in a brief way (and also refer to the file of license information). I would make sure the versions appear in the About box. One thing people want to quickly check for is an indication of whether the copy of your code they have needs to be replaced or updated because one of your library dependencies has a recently-disclosed bug or security vulnerability.

So I guess the other thing you want to include in the about box is a way for people to find your support site and any notices of importance to users of the particular version (whether or not you have a provision in your app for checking on-line for updates).

orcmid