On Mon, Sep 28, 2009 at 12:44 PM, Indrajit Raychaudhuri <[email protected] > wrote:
> > > > On 28/09/09 11:30 PM, David Pollak wrote: > > Indrajit, > > > > Excellent work! > > > > My thoughts inline. > > Thank you :-) My response inlined too. > I say "do it on a branch and see what happens". Do I hear a second? > > /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 > > > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
