|
»
« Return to Thread: Demarcate module boundaries in framework source tree
Re: Demarcate module boundaries in framework source tree
by eokyere
::
Rate this Message:
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 +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
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://www.uwyn.com/mailman/listinfo/rife-devel
>
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 +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
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://www.uwyn.com/mailman/listinfo/rife-devel
>
« Return to Thread: Demarcate module boundaries in framework source tree
| Free embeddable forum powered by Nabble | Forum Help |
