Re: Demarcate module boundaries in framework source tree

> you make is sound more complex that it really is. i am not advocating
> multiple jar files (even though with better demarcation that comes as
> a side effect, if you want) or even suggesting the current jar
> footprint is too large... i'm simply concerned about the cross-package
> dependencies and how difficult it is to tell what exactly the core
> module/package shd consist of and what the supporting modules are.

Why is that of such importance for you? RIFE is a full stack  
framework. Apart from the Swing package, which not many people even  
know that it's there, I consider all the rest part of the 'core' of  
the framework. Anything that I consider not part of it is  already a  
sibling project (RIFE/Crud, RIFE/Search, RIFE/Dav, ...). Crud might  
be merged into the core though and even search too once the tests are  
written for it.

> for instance, if i exclude the ~.swing package, that breaks the
> ~rep.participants package; i don't think this shd be the case... the
> same goes for authentication/engine... i think authentication shd be
> dependent on engine and not the other way around... i think ~.swing
> shd be dependent on ~.rep.participants, and not the other way around.

There is a very simple reason for this, when looking up participants,  
RIFE looks in the com.uwyn.rife.rep.participants package for classes  
so that you can use short names and don't have to specify full  
package names in your particpants.xml. There's no real logic in  
there, it directly delegates to the swing package.

> In fact, the whole ~.rep.participants package looks very fishy... it
> looks like a bunch of concrete implimentations of BlockingParticipant
> buched together... don't they belong in their respective packages...
> i.e. ParticipantConfig in the ~.config package, ParticipantSite in the
> ~.site package and so on... or do some parts of the code look for them
> in that particular location...

See above.

> i remember seeing some code in the
> datasources package that makes explicit use of the package/class name
> when trying to locate drivers for the datasource name passed

Yes, but that's something else, this is how RIFE maps the database  
abstraction to the DB driver or how the driver name of an existing  
javax.sql.DataSource is looked up.

> and of course nothing prevents you from using the same source tree,
> and using symlinks to point to the src, lib folder under differnt
> projects.

Symlinks don't version particularly well and are not supported on  
Windows. Initially (4 years ago) there were quite some of them in the  
source repository, but they have all been removed.

--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage
gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03

PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net