On 28/09/09 11:30 PM, David Pollak wrote:
> Indrajit,
>
> Excellent work!
>
> My thoughts inline.
Thank you :-) My response inlined too.
/Indrajit
>
> On Sun, Sep 27, 2009 at 1:44 PM, Indrajit Raychaudhuri
> <[email protected] <mailto:[email protected]>> wrote:
>
>
> 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-core currently means "everything Lift." I think we need another
> name, but none is jumping out at me.
Firstly, just realized there is a stupid typo. [10] should read [01].
Indeed, lift-core has a different connotation already. Moreover, with
the proposed member modules, a more apt name would help.
>
> - 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 (<packaging>jar</packaging>). 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.
>
>
> From an administrative perspective, having two repositories represents
> twice the work for me, so I'd rather everything from Lift committers
> stays in one repository. With that being said and with our new focus on
> not merging anything into Master without a review-board cycle, I propose
> that we have a "presentations" branch and people put their presos on
> this branch. Whenever someone merges their review-boarded code into
> master, they also merge in the presentations branch.
Ok, so as Heiko suggested, we can have a separate location (not part of
maven build reactor) for this.
>
>
> [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 :)
>
>
> The lift-testkit is supposed to be a set of tools to generate
> integration tests against the application. I would put it in a separate
> high-level package (perhaps lift-modules). It is used during testing,
> but should not, in my opinion, be part of a deployed WAR.
Taken. So lift-testkit could be under lift-modules. And applications
would typically use it under 'test' scope.
>
>
> [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
> <http://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
>
>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
