1) Resource -> Artifact:
It will not be trivial, but we could rename Resource to be Artifact to ease
a merge with Avalon Repository (and since Artifact has started to become a
recognized term).
BTW: I've started to create a page for terms (as Nick suggested):
http://wiki.apache.org/incubator/DepotTerminology
BTW: I figured a similar page for design objectives/tenets would help
communicate:
http://wiki.apache.org/incubator/DepotDesign
Can anybody think of any others?
BTW: We need to get Javadocs for the projects up onto the sites, I think
this'll help us see things from 30 thousand feet, and hence seen
similarities/differences.
2) APIs
I'd like help on how we craft a good API, how we keep it clear and simple.
One problem (as I've noted) is we have all aspects of our code muddled into
one source folder, so we have to rely upon package names to help us separate
& that isn't enough. Maybe without this we need Javadoc help, or something
(Wiki/whatever).
I'd been told that a good API has the main classes in the root package, i.e.
in org.apache.depot.update. That I can believe. Trouble is, the 'Updater'
project is focused towards Updating, so we put ResourceUpdater there. Maybe
we need to add Artifact/Repository, and move ResourceUpdater to a separate
client package (or separate project). Thoughts?
Also, we have things like FileAssistent/FileUpdater (and ClasspathUpdater)
these are higher level 'helpers' for working with ResourceUpdater. Ought
they be in a separate package, so they don't clutter the main access point?
Are they even needed -- or ought our resource API be simple enough they
aren't? Could these be samples?
All input on how to cleanup/make an API appreciated...
regards
Adam
--
Experience the Unwired Enterprise:
http://www.sybase.com/unwiredenterprise
Try Sybase: http://www.try.sybase.com
