Lift 3.0 and sbt
David Pollak
- How should the project be laid out? Right now, the tremendous nesting levels are a challenge to navigate, but are necessary for Maven. Should we flatten the directory structure somewhat?
- Should we use vscaladoc or ScalaDoc2 for Lift 3.0?
- Are there any other top-level items to keep in mind for the sbt-part of the Lift 3.0 effort?
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics
aw
consolidated ScalaDoc -- I miss that from 1.0; having to manage
multiple bookmarks is not as convenient to browse and learn Lift
options. But please don't confuse this desire with a recommendation
to bundle all libraries together -- I very much like the multi-module
approach where I can pick and choose what I am interested in.
Especially for non-web framework stuff like lift-base as I'd like to
use Box and the Json stuff for a non-Lift-web-framework project, for
example.
I don't have much exposure to sbt, so I'm wondering how sbt will solve
things like:
- release management (i.e. the maven-release-plugin)
- site management (i.e. the maven-site-plugin)
Timothy Perrett
Sent from my iPhone
> --
> 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
> .
>
>
Nolan Darilek
Hash: SHA1
On 06/19/2010 01:49 PM, aw wrote:
> But please don't confuse this desire with a recommendation
> to bundle all libraries together -- I very much like the multi-module
> approach where I can pick and choose what I am interested in.
> Especially for non-web framework stuff like lift-base as I'd like to
> use Box and the Json stuff for a non-Lift-web-framework project, for
> example.
>
I don't think the suggestion was to join everything together. Things
would still be modular, but instead of:
framework/lift-base/lift-webkit
the structure might instead be base/lift-webkit, or maybe even just
lift-webkit/. Correct me if I'm wrong.
And I'm very much for flattening things out. I navigate via the console,
and it's annoying to cd
liftweb/framework/lift-persistence/lift-mongodb-record/... just to get
to the sources I need. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwdJy8ACgkQIaMjFWMehWKJaQCcC0+wb+RN5Ep7ECTZa03dHSsm
6/0An281oq+FFquVHWkVMIJVOlvvHxeH
=Qx1h
-----END PGP SIGNATURE-----
Naftoli Gugenheim
Derek Chen-Becker
Heiko Seeberger
To get the ball rolling with Lift 3.0, I'd like to get a volunteer to take the 280_RC6 branch and sbt-ify it (Heiko had indicated interest in the project, so he gets first pick if he's still interested).
- How should the project be laid out? Right now, the tremendous nesting levels are a challenge to navigate, but are necessary for Maven. Should we flatten the directory structure somewhat?
- Should we use vscaladoc or ScalaDoc2 for Lift 3.0?
- Are there any other top-level items to keep in mind for the sbt-part of the Lift 3.0 effort?
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Stambecco, highly scalable computing: stambecco.org
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Indrajit Raychaudhuri
<heiko.s...@googlemail.com> wrote:
> Hi,
>
> On 19 June 2010 19:39, David Pollak <feeder.of...@gmail.com> wrote:
>
>>
>> To get the ball rolling with Lift 3.0, I'd like to get a volunteer to take
>> the 280_RC6 branch and sbt-ify it (Heiko had indicated interest in the
>> project, so he gets first pick if he's still interested).
>
> I am still interested and will try to find the time.
>
Great! Would be happy to help. There is a wip version in the branch
irc_wip_sbt for the framework. That was primarily on sbt-0.7.2. Quite
a few roadblocks have cleared up since. I'll try and pick up the bits
from there. The other roadblock was osgi-fication, that gone because
of bnd4sbt!
>>
>> How should the project be laid out? Right now, the tremendous nesting
>> levels are a challenge to navigate, but are necessary for Maven. Should we
>> flatten the directory structure somewhat?
>
> We probably could get rid of the framework directory.
+1 for getting rid of framework directory. But then archetypes and
examples would become peer of core Lift packages. For example,
lift-persistence being peer to examples would be odd.
How about:
a. Getting rid of the 'lift-' prefixes.
b. Moving framework up to top level (directly on dpp/liftweb/ instead
of dpp/liftweb/framework)
c. Moving examples to top level (dpp/liftweb-examples instead of
dpp/liftweb/examples)
d. Same treatment for archetypes (dpp/liftweb-archetypes instead of
dpp/liftweb/archetypes). And eventually, deprecating archetypes in
favor of launcher based bundles
e. Remove resources
f. Decide on the fate of references (things have changed ever since we
agreed to have docs and presos in references under git)
>>
>> Should we use vscaladoc or ScalaDoc2 for Lift 3.0?
>
> I don't know yet.
Would prefer vscaladoc (but the decision can be deferred).
>>
>> Are there any other top-level items to keep in mind for the sbt-part of
>> the Lift 3.0 effort?
>
> I worked on switching from Maven to SBT for one of my "real-world" projects,
> scala-lang-osgi and Stambecco. I also tuned Akka's SBT build so that the
> time needed for the update action could be reduced from an hour to ten
> minutes. I know everything to build and publish a project to Scala
> Tools. But there might be quite a few things Lift's Maven build offers which
> I don't know, e.g. the "site" thing or ScalaDoc creation. Hence I will need
> some help here.
Scaladoc creation works, but site doesn't. Most folks (at the moment)
take interest in site for the scaladoc part. So in the short term this
might be okay. What say?
> Heiko
> Company: weiglewilczek.com
> Blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
> Stambecco, highly scalable computing: stambecco.org
> Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through
> Actors: akkasource.org
>
David Pollak
- Having framework, examples, and archetypes at the top level makes sense to me. Having lift-base/lift-webkit and the like is the challenge. I'd rather see common, util, webkit, mapper, record, etc. in the framework directory. But to keep the framework directory relatively manageable, I'd suggest having the primary directories at the top level, but having a "secondary" directory (framework/secondary) that can host not-so-frequently used packages (e.g., textile, facebook, OpenID, etc.)
- In documentation engine we use must allow inter-module linking so that every build has cross-linked documentation. Links to NodeSeq, Box, etc. have to take the viewer to the appropriate documentation site. The only advantage that I can see to using ScalaDoc2 is the GSoC project for collaborative documentation building will likely run against ScalaDoc2. DavidB has done an excellent job with VScalaDoc and if he's going to continue to evolve VScalaDoc, that's a compelling reason to use it.
Naftoli Gugenheim
Indrajit Raychaudhuri
the sense that it supports linking to external scaladoc url for other
libraries (via -DpackageLinkDefs).
- Indrajit
On 20/06/10 9:12 PM, Naftoli Gugenheim wrote:
> Is it either or?
>
>
> On Sun, Jun 20, 2010 at 12:22 AM, Derek Chen-Becker
> <dchen...@gmail.com <mailto:dchen...@gmail.com>> wrote:
>
> Agreed. David B. has done some nice things with vscaladoc and the
> Scaladoc2 interface just feels a bit cluttered at the moment.
>
>
> On Sat, Jun 19, 2010 at 1:39 PM, Timothy Perrett
> <tim...@getintheloop.eu <mailto:tim...@getintheloop.eu>> wrote:
>
> It's gotta be vscaladoc, scaladoc 2 is not good from what I've seen.
>
> Sent from my iPhone
>
>
> On 19 Jun 2010, at 19:49, aw <ant...@whitford.com
> <mailto:ant...@whitford.com>> wrote:
>
> I'd vote for ScalaDoc2 over vscaladoc. It would be nice to
> get a
> consolidated ScalaDoc -- I miss that from 1.0; having to manage
> multiple bookmarks is not as convenient to browse and learn Lift
> options. But please don't confuse this desire with a
> recommendation
> to bundle all libraries together -- I very much like the
> multi-module
> approach where I can pick and choose what I am interested in.
> Especially for non-web framework stuff like lift-base as I'd
> like to
> use Box and the Json stuff for a non-Lift-web-framework
> project, for
> example.
>
> I don't have much exposure to sbt, so I'm wondering how sbt
> will solve
> things like:
> - release management (i.e. the maven-release-plugin)
> - site management (i.e. the maven-site-plugin)
>
> -- 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 <mailto:lif...@googlegroups.com>.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>.
> 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 lif...@googlegroups.com
> <mailto:lif...@googlegroups.com>.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>.
> 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 lif...@googlegroups.com
> <mailto:lif...@googlegroups.com>.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>.
Timothy Perrett
great purpose these days.
Anyhow, I think we need to be careful about naming this so called
"secondary" directory, as we don't want those packages to appear as
leper brothers of the most used parts of the framework, otherwise they
will truly fall into disrepair. Moreover, I am actually promoting the
use of lifts modules in my book as it saves developer time, and that
is one of lifts strengths so I think that step must be carefully
considered.
vscaladoc is vastly superior to scaladoc2, which from what i've seen
is ugly as sin.
Regarding the things we are missing in terms of build infrastructure,
why dont we just port the maven plugins to SBT? This is exactly what I
did with my stax.net plugin and it was a simple process (taking only 1
evening) so if there is something specific we need, it shouldn't be
too difficult to port it.
Thoughts?
Cheers, Tim
On Jun 20, 3:42 pm, David Pollak <feeder.of.the.be...@gmail.com>
wrote:
> FWIW:
>
> - Having framework, examples, and archetypes at the top level makes sense
> rather see common, util, webkit, mapper, record, etc. in the framework
> directory. But to keep the framework directory relatively manageable, I'd
> suggest having the primary directories at the top level, but having a
> "secondary" directory (framework/secondary) that can host not-so-frequently
> used packages (e.g., textile, facebook, OpenID, etc.)
> have to take the viewer to the appropriate documentation site. The only
> advantage that I can see to using ScalaDoc2 is the GSoC project for
> collaborative documentation building will likely run against ScalaDoc2.
> DavidB has done an excellent job with VScalaDoc and if he's going to
> continue to evolve VScalaDoc, that's a compelling reason to use it.
>
> On Sun, Jun 20, 2010 at 6:35 AM, Indrajit Raychaudhuri
>
>
>
>
> > On Sun, Jun 20, 2010 at 6:06 PM, Heiko Seeberger
> > <heiko.seeber...@googlemail.com> wrote:
> > > Hi,
>
> > .
> > >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 lif...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net