OK, see what your saying. Perhaps it needs a better name than lift- resources... conceptually I agree though.
Cheers, Tim On 28 Sep 2009, at 21:03, Indrajit Raychaudhuri wrote: > > Tim, > > lift-resources is the place for everything that is not part of regular > Maven build reactor (although some of them could be isolated Maven > module in themselves). This category is different from the other > ones in > that sense - sorry for not being unambiguous enough. > > Obviously, lift-installer cannot be a Maven module, that out of > question! I can see what triggered the confusion though. > > lift-site-skin (can have better name) is basically the substitute of > org.scala-tools.skins:scala-skin-simple. Having own site skin for Lift > would help us have the mvnsite > (http://scala-tools.org/mvnsites/liftweb-1.1-M5/) look similar to > http://liftweb.net which I would much rather ;-) > > Cheers, Indrajit > > > On 28/09/09 11:46 PM, Timothy Perrett 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 >>> >>>> >>> >> >> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
