On 28/09/09 9:45 AM, marius d. wrote:
>
> Generally I like this structure.Please see my other comments below:
Thanks, please see my responses inline.
Cheers, Indrajit
>
> On Sep 27, 3:44 pm, Indrajit Raychaudhuri<[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-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.
>>
>> [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)
>
> I'm not sure about base interfaces for lift ...
The description says: "Base Interfaces for Lift and perhaps other
frameworks". But looking at the dependencies in dpp_wip_actorized,
lift-actor and/or lift-util would depend on this (Box has moved there).
David is probably working on expanding this (it's wip afterall) and can
can comments.
>
>>
>> [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)
>
> JSON should not only be part of JS stack as it is used in many
> contexts for REST API's. So I'd keep it in the core,
Agreed. So core it is :)
>
>>
>> [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.
>
> Why splitting it up? .. .the webkit if the very core of lift.
Indeed, that's how it is currently. But the way I see this is: A part of
webkit (not whole of it) should be part of core of lift.
The intent is to have (almost) all of webkit that every project would
need as part of core. For example, 'headless' applications would have
nothing to do with the YUI, JQuery libraries that are currently part of
webkit.
One of the ways to achieve this could be to move net.liftweb.http.js
into separate package. And then there is overall discomfort that a
member of the core library has gained lot of weight (the jar is 2.5M) at
the moment! Just a discomfort, not showstopper and thus de-prioritized
at the moment.
>
>>
>> [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.
>
> I definitely agree.
>
>>
>> [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
>
> I would definitely keep them separated from core/webkit.
I'll keep note of this. Would like to take up together with [04]
>
>>
>> [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.
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
-~----------~----~----~----~------~----~------~--~---
