Excellent proposal! Heiko
On Friday, November 27, 2009, Indrajit Raychaudhuri <indraj...@gmail.com> wrote: > Folks, > > In continuation to the refactoring initiative and following up on the > discussion that we had on the last committers call, here we have the > next round of broad based project structure refactoring proposal. This > is themed around the idea of splitting the build system into separate > smaller 'projects' with clearly demarcated responsibilities between > them. In the way, these projects can have independent life-cycles on > their own without coming in the way of each other (but still continue > to have a dependency hierarchy). > > Here are the set of projects to begin with: > > 1. framework (http://github.com/dpp/liftweb/tree/<branch>/framework): > The regular Lift as we have today (minus lift-archetype, lift- > examples, lift-misc). > Thus we would have: > framwork/pom.xml > framwork/lift-base > framwork/lift-persistence > framwork/lift-modules > > > 2. archetypes (http://github.com/dpp/liftweb/tree/<branch>/ > archetypes): > The lift-archetypes from Liftweb. > archetypes/pom.xml > archetypes/lift-archetype-blank > archetypes/lift-archetype-basic > archetypes/lift-archetype-jpa-blank-single > archetypes/lift-archetype-jpa-blank > archetypes/lift-archetype-jpa-basic > > > 3. examples (http://github.com/dpp/liftweb/tree/<branch>/examples): > The lift-archetypes from Liftweb. The big uptake for archetypes and > examples is the reduction of build time for building full Lift. > Individuals building Lift might not always be interested in building > non ancillary packages like lift-archetypes and lift-examples. > examples/pom.xml > examples/<example1> > examples/<example2> > > 4. resources (http://github.com/dpp/liftweb/tree/<branch>/resources: > > 4a. project-parent: A pure POM based project to be canonically used by > all Lift family of projects (liftweb, lift-archetype, lift-examples > etc.). Lot of what has gone in liftweb/pom.xml should get moved here. > Obviously, this would contain the most generic configuration that > holds true for all projects of Lift (#1, #2, #3). > > 4b. site-skin: Lift specific site skin instead of relying on org.scala- > tools.skins:scala-skin-simple > > 5. references (http://github.com/dpp/liftweb/tree/<branch>/ > references): > Lift documentations and presentations. These don't need to show up in > the project hierarchy in the IDE. > > 6. installer (http://github.com/dpp/liftweb/tree/<branch>/installer): > The usual lift-installer that is tucked inside lift-misc. Again, these > are unnecessarily showing up in the project hierarchy in the IDE. > > I am floating the idea beforehand and would be keen to have input from > committers, the pros and cons and any other general feedback before > proceeding. > > Thoughts would be very welcome :) > > Cheers, Indrajit > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@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. > > > -- 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 lift...@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.
