Yes, in public repos this is possible. Take a look at ScalaModules, there I did this.Only thing is, you got no version control. But for presos that's probably not neccessary.
=> Let's put non-code (presentations) to Downloads. Heiko 2009/9/28 Viktor Klang <[email protected]> > > > 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 > > > > -- Heiko Seeberger My job: weiglewilczek.com My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
