Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Convention for a distribution package

Thread Tools

Convention for a distribution package

Ahmed Moustafa
Posts: n/a
Is there a convention to what to include (folders and files) in an open
source package?

Reply With Quote
Harald Hein
Posts: n/a
"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.

Reply With Quote
Brian Palmer
Posts: n/a
Ahmed Moustafa <(E-Mail Removed)> 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
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
single package import v/s the entire package Parvinder Java 6 02-27-2005 02:02 PM
rpa local distribution package or sort of.. Peņa, Botp Ruby 1 09-19-2004 11:58 AM