|
»
« Return to Thread: Demarcate module boundaries in framework source tree
Re: Demarcate module boundaries in framework source tree
by Geert Bevin
::
Rate this Message:
> 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 +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
> 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 +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
« Return to Thread: Demarcate module boundaries in framework source tree
| Free embeddable forum powered by Nabble | Forum Help |
