Demarcate module boundaries in framework source tree

[eokyere]

I think the rife framework source tree shd be broken up into its
proper constituent modules to properly demarcate what the optional
packages are and also to make dependencies more clearer.

currently, the way i understand it, the source tree holds the core
framework (engine, cmf, config, rep, resources, site, xml),
authenticatation, tools (i'm not sure if this is part of the core
framework), gui (optional), database (optional in a way?), mail
(optional?), scheduler (not sure where this belongs yet), swing (part
of gui?)

I'm asking for this because I'm not sure exactly what to limit myself
to (or what else gets broken) when I'm looking to make changes
locally. Demacating the code into proper modules (not just packages)
shd also it easier to track bugs/send patches up.

Or is there a way to properly download these individually (together
with dependencies) without corrupting the tree with extraneous source
files?

Thoughts?

Thanks,
eokyere

[Geert Bevin]

> I think the rife framework source tree shd be broken up into its
> proper constituent modules to properly demarcate what the optional
> packages are and also to make dependencies more clearer.

This is very complex since everything is very well integrated. We  
spent quite some time to create a build target for DB-specific  
features though.

You will not gain much by leaving out the most of the non core parts.  
The RIFE is jar is only a mere 2.5M, everything included.

> currently, the way i understand it, the source tree holds the core
> framework (engine, cmf, config, rep, resources, site, xml),
> authenticatation, tools (i'm not sure if this is part of the core
> framework), gui (optional), database (optional in a way?), mail
> (optional?), scheduler (not sure where this belongs yet), swing (part
> of gui?)

I don't feel much for having a collection of separated modules that  
people should carefully recompose. RIFE is a full stack framework and  
2,5MB is a small size nowadays. Users can just use the full jar and  
pick the features they need.

> I'm asking for this because I'm not sure exactly what to limit myself
> to (or what else gets broken) when I'm looking to make changes
> locally. Demacating the code into proper modules (not just packages)
> shd also it easier to track bugs/send patches up.

When you want to make changes, the best thing is to discuss what  
you're doing first to see if you can't break things. Gradually you'll  
get a better view of the system and know better how to develop on it.  
Note that the web engine itself, more particularly the data and logic  
flow handling, is extremely complex and I don't encourage you to  
delve into that. Don't forget that the fact that constraints, for  
example, are automatically handled by all the parts of the framework  
is what makes RIFE so easy to use. Apart from that, the tools and the  
IoC property handling not much bleeds over. The packages are fairly  
well separated.

RIFE has an extremely comprehensive testsuite. This also gives you a  
lot of guidance when making changes.

The modules are very close to the packages, just look at the issue  
tracker.

> Or is there a way to properly download these individually (together
> with dependencies) without corrupting the tree with extraneous source
> files?

What do you mean by this?
--
Geert Bevin                       Uwyn bvba
"Use what you need"               Avenue de Scailmont 34
http://www.uwyn.com               7170 Manage, Belgium
gbevin[remove] at uwyn dot com    Tel [phone]

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

[eokyere]

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.

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.

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... 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

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.

-- eokyere

On 12/16/05, Geert Bevin <gbevin@...> wrote:

> > I think the rife framework source tree shd be broken up into its
> > proper constituent modules to properly demarcate what the optional
> > packages are and also to make dependencies more clearer.
>
> This is very complex since everything is very well integrated. We
> spent quite some time to create a build target for DB-specific
> features though.
>
> You will not gain much by leaving out the most of the non core parts.
> The RIFE is jar is only a mere 2.5M, everything included.
>
> > currently, the way i understand it, the source tree holds the core
> > framework (engine, cmf, config, rep, resources, site, xml),
> > authenticatation, tools (i'm not sure if this is part of the core
> > framework), gui (optional), database (optional in a way?), mail
> > (optional?), scheduler (not sure where this belongs yet), swing (part
> > of gui?)
>
> I don't feel much for having a collection of separated modules that
> people should carefully recompose. RIFE is a full stack framework and
> 2,5MB is a small size nowadays. Users can just use the full jar and
> pick the features they need.
>
> > I'm asking for this because I'm not sure exactly what to limit myself
> > to (or what else gets broken) when I'm looking to make changes
> > locally. Demacating the code into proper modules (not just packages)
> > shd also it easier to track bugs/send patches up.
>
> When you want to make changes, the best thing is to discuss what
> you're doing first to see if you can't break things. Gradually you'll
> get a better view of the system and know better how to develop on it.
> Note that the web engine itself, more particularly the data and logic
> flow handling, is extremely complex and I don't encourage you to
> delve into that. Don't forget that the fact that constraints, for
> example, are automatically handled by all the parts of the framework
> is what makes RIFE so easy to use. Apart from that, the tools and the
> IoC property handling not much bleeds over. The packages are fairly
> well separated.
>
> RIFE has an extremely comprehensive testsuite. This also gives you a
> lot of guidance when making changes.
>
> The modules are very close to the packages, just look at the issue
> tracker.
>
> > Or is there a way to properly download these individually (together
> > with dependencies) without corrupting the tree with extraneous source
> > files?
>
> What do you mean by this?
> --
> Geert Bevin                       Uwyn bvba
> "Use what you need"               Avenue de Scailmont 34
> http://www.uwyn.com               7170 Manage, Belgium
> gbevin[remove] at uwyn dot com    Tel [phone]
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 309F D6A9
> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://www.uwyn.com/mailman/listinfo/rife-devel
>

[Geert Bevin]

> 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 [phone]

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