Re: [Lift] Refactoring Round 2

2009-11-30 Thread David Pollak
On Fri, Nov 27, 2009 at 7:30 AM, Heiko Seeberger 
heiko.seeber...@googlemail.com wrote:

 Excellent proposal!


+1



 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.comliftweb%2bunsubscr...@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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.





-- 
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

--

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.




[Lift] Refactoring Round 2

2009-11-27 Thread Indrajit Raychaudhuri
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.




Re: [Lift] Refactoring Round 2

2009-11-27 Thread Heiko Seeberger
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.