Refactoring Round 2

10 views
Skip to first unread message

Indrajit Raychaudhuri

unread,
Nov 27, 2009, 8:24:17 AM11/27/09
to Lift
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

Heiko Seeberger

unread,
Nov 27, 2009, 10:30:47 AM11/27/09
to lif...@googlegroups.com
Excellent proposal!

Heiko
> --
>
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@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

David Pollak

unread,
Nov 30, 2009, 6:45:44 PM11/30/09
to lif...@googlegroups.com


On Fri, Nov 27, 2009 at 7:30 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:
Excellent proposal!

+1
 



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
Reply all
Reply to author
Forward
0 new messages