Convention for a distribution package

Discussion in 'Java' started by Ahmed Moustafa, Aug 23, 2003.

  1. Is there a convention to what to include (folders and files) in an open
    source package?
    Ahmed Moustafa, Aug 23, 2003
    1. Advertisements

  2. Harald Hein

    Harald Hein Guest

    "Ahmed Moustafa" wrote:

    > Is there a convention to what to include (folders and files) in an
    > open source package?

    At least the source code :)

    I would suggest you e.g. go to the fsf web site and have a look at some
    GNU packages and their organisataion. I personally like tar files (for
    java that would be zip/jar archives) with the following structure:

    All stuff start under one directoy in the archive, containing the name
    and the version of the software, and then some easy to identify text
    files and subdirs. A simple package layout might look like:

    <name>-<version>/README - ASCII file explaining the package and
    providing contact details, installation
    instructions etc.
    INSTALL - If the build and installation procedure
    is more complex and isn't in the README.
    I don't like it too much. I prefer to
    have everything in the README
    COPYING - The license if you use the GPL or a
    similar file like COPYRIGHT or LICENSE
    containing your license.
    ChangeLog - What has changed between versions
    Makefile - Root file of the build system. If you
    don't use makefiles then something
    specific to your build system (ant).
    If you want to be nice to your users,
    DON'T use anything fancy which requires
    any additional installation. DON'T use
    non-standard or the latest features of
    the build system. It should work with
    the oldest version of the build tool
    one can imagine.
    src/ - source code
    doc/ - documentation
    examples/ - guess what :)
    test/ - test programs

    For Java you might consider to deliver an additional package that
    contains a pre-compiled version (.class class files) of your software.
    That package should blend-in well with the source distribution (can be
    installed in the same directory, so should not overwrite each other's
    files), also contain the license and a pointer to the source

    If your software relies on other libraries, non-standard build tools,
    etc. (anything that requires additional downloads), consider offering a
    complete package for download, too.

    Harald Hein, Aug 23, 2003
    1. Advertisements

  3. Brian Palmer

    Brian Palmer Guest

    Ahmed Moustafa <> writes:

    > Harald Hein wrote:

    > Harald, thank you so much for your reply!!!
    > Should all these elements be held under cvs? Or only the source code?

    Basically, any fundamental element that can change, should be entered
    into cvs (or whatever revision-control system you're using). For
    example, keeping the contents of
    in your CVS repository is a good idea, if you've spent time creating a
    manual. This is probably version-specific, so when you check out a
    past version of your product, you want to get the manual that's
    associated with it. When you make revisions to the product, you should
    plan on updating the manual, and you'll want to track those changes,

    But if all doc/ is for is piping javadoc output, there's no point in
    adding it to cvs, since you can always regenerate it from the source
    code that you checked out.

    See for java-related announcements
    Brian Palmer, Aug 24, 2003
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Parvinder
    Thomas G. Marshall
    Feb 27, 2005
  2. Dave
  3. George P
    Alex Martelli
    Sep 11, 2004
  4. David Pratt
    David Pratt
    May 13, 2006
  5. Peña, Botp
    Mauricio Fernández
    Sep 19, 2004

Share This Page