Heiko, That looks like the initial check-in I did on the branch. There has been quite a few commits since.
I double checked to ensure the git push. Seems fine. Looks like the little bird agrees too :) [http://twitter.com/liftweb/status/6862128603] Cheers, Indrajit On 21/12/09 3:41 PM, Heiko Seeberger wrote: > Indrajit, > > Great to see the next refactoring round! > > I got the branch and there are a lot of oddities, e.g.: > > * All the POMs I looked at are still 1.1, not 2.0 > * framework/pom.xml references module lift-archetypes and lift-examples > * The parent POM is empty > > Maybe you did not update the branch on GitHub with your latest changes? > > Heiko > > 2009/12/20 Indrajit Raychaudhuri <[email protected] > <mailto:[email protected]>> > > Okay Folks, > > Lift 2.0 branch has shaped up enough for everybody to play with. > Checkout the branch irc_wip_lift20 and get going! Just be aware that > it's still undergoing updated and changes incrementally and there are > few rough edges. > > Key changes: > > 1. The project tree has been restructured according to the proposal > sent out earlier [1]. To summarize, we now have three top level > projects (framework, archetypes and examples) each with independent > build life-cycle. There are other additional infra projects that are > less to do with the actual code. > > A quick summary of the top-level projects: > > 1. Framework: > The whole of Lift Framework that matter most to most. The usual > modules (viz., lift-base, lift-persistence and lift-modules) have got > nested within. Therefore, from now on, building Lift framework would > mean just that. Doing a "git pull" or "git clone" as usual, changing > to framework directory and running "mvn install". > > 2. Archetypes: > The standard distributed archetypes. The archetypes help you get quick > started with a Lift based project. If you are not into building maven > archetypes, you can stay clear of this. But a quick probe is welcome. > > 3. Examples: > All the Lift examples are grouped into this project. If you are > generally interested in learning different techniques from examples > you don't have to build the whole of Lift anymore. Well that was still > the case earlier, but now it's even more obvious. And it's true the > other way round too, if you have to build Lift framework from source, > you don't have to build the examples along with it. Another point: the > examples won't be deployed on scala-tools maven repo anymore. Those > war files up there serve no good purpose. > > Everything now gets neatly tucked into their respective homes :) > > Additional points that you should be aware of: > > A. Availability on scala-tools repository: > - Components of framework would be available > - Components of archetypes would be available > - Components of examples would *not* be available > > B. Availability on scala-tools Maven site: > Site generated from framework would be the main content of scala-tools > Maven site. Depending on how things go, we might even have a home of > it's own at http://dev.liftweb.net. (Separate proposal coming up) > > C. Lift Parent Project Model: > The top level pom.xml has moved to it's own home at resources/project- > model. This would stay as a 'flyweight' project (as in boxing, not > GoF) on it's own that would strictly control the common behavior, > plugin dependencies, versions etc. for all the top level projects > (framework, archetypes, examples). This would be deployed on scala- > tools repository. > > D. Lift Site Skin (WIP): > I haven't started working on this yet. But the intent is to create a > project site that is of some real value and serves as placeholder for > mostly 'auto-generated' docs. See #B above. > > E. Still pending: > a. Migration to Scala 2.8 branch. Intend to have stable master created > first with everything working as usual without being caught into Scala > release cycle. Hopefully, this branch and '280_port' would merge soon! > b. Higher quality site generation (See #B above, proposal coming up) > c. Site skin (See #D above) > d. Hudson integration and better release management. So that certain > steps in Committer release process [2] become automatic (waiting for > merge to master and hudson maintenance) > e. Having a nice README.md at the top level > f. General spit and polish > > F: To be decided: > a. Future of lift-core. (Separate mail coming) > b. Relevance of OtherLicensedWorks.txt (repo distribution of javamail > is now under CDDL and license automatically reflects in dependency > page) > c. Need for remove-trailings.sh (can be replaced by git pre-commit > hook) > > > [1] > > http://groups.google.com/group/liftweb/browse_thread/thread/450a3e741999b5df > [2] http://wiki.github.com/dpp/liftweb/committer-release-process > > Feedbacks most welcome! > > Cheers, Indrajit > > > > > -- > Heiko Seeberger > > My job: weiglewilczek.com <http://weiglewilczek.com> > My blog: heikoseeberger.name <http://heikoseeberger.name> > Follow me: twitter.com/hseeberger <http://twitter.com/hseeberger> > OSGi on Scala: scalamodules.org <http://scalamodules.org> > Lift, the simply functional web framework: liftweb.net <http://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. -- 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.
