Folks,
As followup to the proposed goal of "Keeping lift-core neat and
small", here is the first iteration of the revised structure of Lift
codebase.
liftweb
- lift-core [10]
- lift-base [02]
- lift-actor
- lift-util
- lift-json [03]
- lift-webkit [04]
- lift-testkit [05]
- lift-persistence [06]
- lift-mapper
- lift-record
- lift-jpa
- lift-modules [07]
- lift-osgi
- lift-wizard [08]
- lift-widgets [09]
- lift-machine
- lift-textile
- lift-facebook
- lift-amqp
- lift-xmpp
- lift-openid
- lift-oauth
- lift-paypal
- lift-jta
- lift-archetypes
- ...
- lift-examples
- ...
- lift-site [10]
- lift-resources [lift-varia, lift-infra ?] [11]
- lift-root-model [12]
- lift-site-skin
- lift-installer
- misc config resources (scaladoc, javadoc etc.)
General notes (including some obvious ones):
[A] lift-* prefix looks superfluous, but it's best to have one for all
artifacts that generate jar (jar). Also Maven
reactor feels happier when artifactId == directory_name (site
generation, scm extrapolation etc., situation might have improved
now).
[B] The top level project categories (lift-core, lift-persistence,
lift-modules etc.) are simple multi-module models at the moment and
not meant to create anything other than pom. Therefore, lift-* prefix
can go away. But they'll have to come back if we plan to generate 'one
jar' in assembly mode per category (lift-core-all.jar, lift-
persistence-all.jar etc.). This could be useful for 'get me
everything, I don't care about size' people. But is it necessary? The
alternative is to have empty 'meta modules' that pull up the necessary
dependencies and can be included by the users in their project (quite
similar to what lift-core does now).
[C] The members in a project category (lift-mapper, lift-record etc.)
would inherit the category model (lift-persistence in case of lift-
mapper, lift-record). Related modules clubbed together helps similar
configuration pulled up to the parent pom (improves DRY-ness). Added
benefit: modules can be developed even outside Lift codebase with the
given parent pom (available in global repo) and the developer won't
have to worry about most of the infra related boilerplate
configurations (couple of config still would need change though).
[D] Presentations and other materials aren't really source code for
inclusion in source repository. Can this go in wiki? (immediate
problem: github doesn't take attachment). Has this been discussed
earlier? They can go as a separate github project too.
[E] The categorization is mostly based on my interpretation as a late
entrant. If there is a different structure that fits the philosophy
better (quite likely), this would get regrouped. (Tim ?)
[F] The modules in a category can be further sub-grouped, but with
caution. Basically, need the right mix between 'flat'-ness and deep
nesting. Thoughts on this?
[G] Each category can eventually be split up into separate projects
and have their own release schedules (less frequent for core, more
frequent for modules etc.). This might be little overkill at the
moment. Just mentioned to enable us mind the long term perspective :)
[H] Other points on the draft hierarchy (see the # in brackets above):
[01] With these members, if lift-core doesn't sound as the right name,
we need the right name. Provided the grouping is right that is.
[02] Base interfaces for Lift (currently present in dpp_wip_actorized)
[03] Doesn't really have to be part of Lift core in current form, but
this is eventually meant to be part of Lift's JS infrastructure (thus
kept here at the moment)
[04] Candidate for decomposition. But kept intact at the moment. Would
be taken up in next pass once the top level reaches steady state. This
could either become a category of its own or a module with submodules.
[05] Little unsure about it's intent and purpose, I could be
completely mis-interpreting this. Thoughts from somebody with more
understanding please :)
[06] Doesn't have to be part of lift-core. Lift applications not using
persistence doesn't have to need this.
[07] Extra stuff, necessary iff one needs. Right now, I am putting
'everything else' here for lack of better place, but I see a scaling
up issue there. This can turn out to be a place for all the 'nowhere
else to go' modules. But we can take it up in next pass. Suggestions?
[08][09] See #04 above. Can be subpackage of lift-webkit eventually
[10] The website! The intent is to bring liftweb.net codebase into the
streamlines structure. Can be deferred if this is not a burning need.
[11] Recommendation for a good name?
[12] The top level pom for Lift project. All models (the categories)
are expected to inherit this. These categories doesn't necessarily
have to belong to the same git repo.
Let the discussion/debate begin!
Cheers, Indrajit
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Lift" group.
