Dennis Reedy (JIRA) wrote:
I dont see any reason to keep service-ui.jar in the mix as an additional
artifact. The service UI work seems to fit in very nicely with the intent and
purpose of jsk-dl (river-dl), breaking it out into it's own module seems
overkill IMO.
I would like to move ahead and change:
river-dl -> river-api
I think keeping river-lib as-is for now makes the most amount of sense. With
this approach,
river-lib -- depends-on --> river-api
Clients that want to use the service interfaces in river-api need only to
include river-api in their classpath as a direct dependency. Consider if they
want to simply discover a JavaSpace today, clients need to include (at least)
jsk-dl.jar in their classpath (most likely clients include jsk-lib in their
classpath).
I'm going to construct a graph of all class dependencies in River, since
this seems like an opportune time to investigate why things are the way
they are and whether there is opportunity for improvement.
Cheers,
Peter.
