Indrajit, What is the purpose of lift-resources? We cannot make the lift installer part of the build process - belive me, i've looked into this extensively... basically, it boils down to needed install4j licensed on that machines which would be a stupid requirement to place on any person building the sources - so we wont be doing that ;-)
What the hell is lift-site-skin? Cheers, Tim On 27 Sep 2009, at 21:44, Indrajit Raychaudhuri 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) > > [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. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
