On Mon, Sep 28, 2009 at 9:08 PM, Viktor Klang <[email protected]>wrote:
> Can't the presentations be added as binaries to GitHub, and then link to > them from the wiki? > > Under "Downloads" I mean. > > 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 > -- 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 -~----------~----~----~----~------~----~------~--~---
