Actually check out Module instead.
For package management see DroidRepository ...
Maybe the fundamental unit of Droid should be the package. A package is contained wholly within a folder, with all source code in the immediate folder.
Here is an example, expressed in OGDL which I consider quite readable:
package xing_foo_bar
version 1.00
api description \
Foo bar baz.
using
org_std_aw
org_opengl_es *
org_moo_fuzz fuzz
org_foo_bar (Date, Time, Format)
org_x_y 1.00 1.10 *
authors
maintainers
"Me Me Me" _foo@ahnfelt.dk http://ahnfelt.dk
contributors
peter@example.com
"Miriam" http://www.example.com/miriam
license "Public Domain"
The first line is mandatory and defines the name of the package. A package name is separated by underscores into words, each of which can contain only the English letters a-z and numbers, although the first character in each word must be a letter. The package name must match the containing folder's name (case sensitive). Please consider using your internet domain name as a prefix. For example, I own ahnfelt.dk, so if I were to make some date tools, I might place it in dk_ahnfelt_date.
Version may be listed. The version is assumed to be 0.01 if left out. The hash of the folder contents will be used as the build identifier.
API documentation that applies to the entire package may be added, as we have done on the two following lines.
Dependencies, if any, are listed under the using clause. Each sub item is a package name, followed by one of the following:
Nothing - just make the package available, any use is explicit.
An asterix - make everything from the package available in the global namespace.
A package name - make the package available through an alias.
A list of top-level names - make these available in the global namespace, and use the rest explicitly.
If a name in the dependencies can refer to multiple types or objects, it is hidden so that you must use the fully qualified name. If any package name (including aliases and the defining package's) occurs twice, it is an error. If the source code of a package defines a name that clashes with a name in the using-clause, the one in the using-clause is hidden, whereas the one in the current package remains visible. Right after the package name a minimum version or a minimum and a maximum version can be listed.
Authors may be listed. Each author may have a name, an e-mail, and/or an URL. They are put into two categories - people who are currently maintaining the package (maintainers), and everybody else who have contributed (contributors).
The license text for the entire package can be stated too.
The order shown in the example above is the recommended one, although it can be in any order.
Dependencies (and their dependencies, recursively) should automatically be fetched when needed, or at least this should be an option to the user. Compilation (or other forms of analysis) should consider the package as a whole unit.
Under each package there could be some standard folders. Say we have the package x_y_z:
x_y_z/
package.ogdl
Foo.droid
Bar.droid
private/
Baz.droid
test/
TestFoo.droid
resources/
icon.png
api/
x_y_z_q/
x_y_foo_bar/
The immediate package folder contains the package description package.ogdl and the source code containing public symbols. The private/ folder contains sources with package private symbols. The test/ folder contains unit tests. The resources/ folder contains resources (available at runtime, typically settings and binary data). The api/ is where the help generated by examining source code and doc comments go.
The two other package folders are present to demonstrate that even though x_y_z_q is intuitively a "sub package" of x_y_z, it is actually a completely separate package with no special connection to x_y_z or x_y_foo_bar. In that sense, each package is self-contained, and the only inter-package dependencies are specified in the using clause in each package's package.ogdl.