Can't the presentations be added as binaries to GitHub, and then link to them from the wiki?
On Mon, Sep 28, 2009 at 8:16 PM, Timothy Perrett <[email protected]>wrote: > > 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 > > > > > > > > > > > > -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
