[Lift] Re: [lift] Building Lift with scala 2.8.0
bearfeeder wrote: Do you have a production app that depends on Scala 2.8? Is there a part of Lift that you immediately need ported to 2.8? No, I don't have an immediate need. However, I am very likely to be starting on a new app in mid January which will launch in the middle of next year. I am keen to use 2.8.0 because, well, I'm a geek and like shiny new things. I could start with 2.7.7 and port it later, but if I can use the 2.8 port, and contribute feedback etc, I would like to. Channing -- View this message in context: http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26861997.html Sent from the liftweb mailing list archive at Nabble.com. -- 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] Re: How can i get the user IP address in the lift ?
Personally, i'd drop the lambda, and do: S.containerRequest.map(_.remoteAddress).openOr(localhost) the map returns a Box[String], so we can get access and provide a handy default if need be. If you dont want that, just do a pattern match or whatever you want. Cheers, Tim On Dec 20, 2:38 am, Jarod Liu liuyuan...@gmail.com wrote: S.containerRequest.map(r=println(r.remoteAddress)) On Dec 20, 4:18 am, Neil.Lv anim...@gmail.com wrote: Hi all, I want to get the IP address of the users. How can i get the remote IP address in the lift? Thanks for any suggestion! Cheers, Neil -- 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] Re: Documentation Site
1.0 is the last official release that was not a milestone or snapshot - thus, they are the primary api docs right now until we release 2.0 (that is, what was being called 1.1 is being renamed to 2.0). API docs are a process issue, and handled as part of our build process - they will always live both on scala-tools and liftweb.net where applicable. They wont ever sit anywhere else (officially). Yes, the wiki is a little out dated. I forget the number of times i've tried to spear head a wiki effort... the bottom line is that other people need to start writing content - there are a fair number of competent lift users in the community who simply are not giving anything back by way of articles or wiki cleaning - thus our docs get out dated fast because the team prefer to write code than documentation. We even tried to appointed a wiki gardener but he appears to have just disappeared into the ether... Id be open to hearing suggestions on how one could keep the wiki more up to date? Short of users actually contributing back, there is a limit on what the team can do at anyone time. We are getting there, but its not going to be an overnight process. Blogs - a fundamental corner stone of the internet and your right, they are a great information repository. Perhaps we could syndicate some blogs onto liftweb.net during the rewrite (yes, im going to rewrite it at last!)... certainly open for that. Cheers, Tim PS: Sorry that was a bit of a rant, but this is a frustrating issue that i've been pushing for over a year ;-) On Dec 19, 1:16 pm, Hannes hannes.flo...@gmx.li wrote: Definitely! I would like one location for everything, but I believe that the current situation is not like that. - there two API docs 1.0 and 1.1, the latter is hard to find - there's liftweb.net (a little bit out-dated) - there's the Wiki - there's David's Blog (that has some unique information) What did I forget? thanks. Why not improve the existing wiki on github? Or fork the book and make improvements that way? I'm not opposed to additional resources, but why create another place where docs may or not be out of date? I think that Lift is still at the point where one location of docs is better. My opinion. On Dec 19, 6:37 am, Hannes hannes.flo...@gmx.li wrote: Hi Lifters, I'm thinking about setting up a site that takes together all available information about Lift (Links, News, ...). I would like to know, if this would be appreciated or not. I still think that all the available information is to much spread out - specially for people who get started with Lift. In case of positive responds, I would like to setup a Plone (CMS) site. I think its a really good tool, to organize content. thanks for listening. -- 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 athttp://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 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] Re: [lift] Building Lift with scala 2.8.0
I could start with 2.7.7 and port it later, but if I can use the 2.8 port, and contribute feedback etc, I would like to. Feedback would be great: Very welcome! 280_port should build without failures: Could you please tell me exactly, what is breaking your build? Heiko Channing -- View this message in context: http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26861997.html Sent from the liftweb mailing list archive at Nabble.com. -- 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.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] [lift] Building Lift with scala 2.8.0
2009/12/19 Channing Walton channingwal...@mac.com I would like to use Lift with scala 2.8.0 but need some helping building the branches. I've checked out the 280_port branch, but when I set the scala version to 2.8.0.Beta1-RC3 in the main pom, Lift doesn't compile. Hmm, the main POM of the 280_port has already set the scala version ot 2.8.0.Beta1-RC3! Are you sure you are using 280_port? Heiko 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.
[Lift] Re: Re: [lift] Building Lift with scala 2.8.0
ok here it is. The only thing I changed in the main pom is the scala version
to the 2.8.0 beta rc3
[INFO] Compiling 2 source files to
/Users/channing/tmp/280_port/lift-base/lift-common/target/test-classes
error: error while loading Sugar, Scala signature Sugar has wrong version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/specs/1.6.1/specs-1.6.1.jar(org/specs/Sugar.class)
error: error while loading Runner, Scala signature Runner has wrong version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/specs/1.6.1/specs-1.6.1.jar(org/specs/runner/Runner.class)
error: error while loading JUnit, Scala signature JUnit has wrong version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/specs/1.6.1/specs-1.6.1.jar(org/specs/runner/JUnit.class)
error: error while loading Console, Scala signature Console has wrong
version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/specs/1.6.1/specs-1.6.1.jar(org/specs/runner/Console.class)
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxSpec.scala:23:
error: too many arguments for constructor Object: ()java.lang.Object
class BoxSpecTest extends Runner(BoxSpec) with JUnit with Console
^
error: error while loading Specification, Scala signature Specification has
wrong version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/specs/1.6.1/specs-1.6.1.jar(org/specs/Specification.class)
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxSpec.scala:25:
error: value can is not a member of java.lang.String
A Box can {
^
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxSpec.scala:58:
error: value should is not a member of java.lang.String
A Box should {
^
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxSpec.scala:66:
error: value should is not a member of java.lang.String
A Full Box should {
^
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxSpec.scala:149:
error: value should is not a member of java.lang.String
An Empty Box should {
^
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxSpec.scala:214:
error: value can is not a member of java.lang.String
A Failure is an Empty Box which can {
^
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxSpec.scala:225:
error: value should is not a member of java.lang.String
A Failure is an Empty Box which should {
^
error: error while loading Gen, Scala signature Gen has wrong version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/scalacheck/1.6/scalacheck-1.6.jar(org/scalacheck/Gen.class)
error: error while loading Arbitrary, Scala signature Arbitrary has wrong
version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/scalacheck/1.6/scalacheck-1.6.jar(org/scalacheck/Arbitrary.class)
error: error while loading Prop, Scala signature Prop has wrong version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/scalacheck/1.6/scalacheck-1.6.jar(org/scalacheck/Prop.class)
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxUnit.scala:29:
error: too many arguments for constructor Object: ()java.lang.Object
class BoxUnitTest extends Runner(BoxUnit) with JUnit
^
error: error while loading ScalaCheck, Scala signature ScalaCheck has wrong
version
expected: 5.0
found: 4.1 in
/Users/channing/.m2/repository/org/scala-tools/testing/specs/1.6.1/specs-1.6.1.jar(org/specs/ScalaCheck.class)
/Users/channing/tmp/280_port/lift-base/lift-common/src/test/scala/net/liftweb/common/BoxUnit.scala:31:
error: value should is not a member of java.lang.String
A Box equals method should {
^
18 errors found
--
View this message in context:
http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26862311.html
Sent from the liftweb mailing list archive at Nabble.com.
--
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] Re: [lift] Building Lift with scala 2.8.0
If I skip tests:
[INFO] Compiling 3 source files to
/Users/channing/tmp/280_port/lift-base/lift-actor/target/classes
/Users/channing/tmp/280_port/lift-base/lift-actor/src/main/scala/net/liftweb/actor/LAFuture.scala:19:
error: not found: value common
import common._
^
/Users/channing/tmp/280_port/lift-base/lift-actor/src/main/scala/net/liftweb/actor/LiftActor.scala:18:
error: not found: value common
import common._
^
/Users/channing/tmp/280_port/lift-base/lift-actor/src/main/scala/net/liftweb/actor/LiftActor.scala:42:
error: type mismatch;
found : AnyRef{def run(): Unit}
required: java.lang.Runnable
es.execute(new Runnable{def run() {f()}})
^
/Users/channing/tmp/280_port/lift-base/lift-actor/src/main/scala/net/liftweb/actor/LiftActor.scala:183:
error: missing parameter type for expanded function ((x0$1) = x0$1 match {
case (e @ _) = ()
})
protected def exceptionHandler: PartialFunction[Throwable, Unit] = {
^
/Users/channing/tmp/280_port/lift-base/lift-actor/src/main/scala/net/liftweb/actor/LiftActor.scala:210:
error: type mismatch;
found : net.liftweb.actor.MsgWithResp
required: T
this ! MsgWithResp(msg, future)
^
/Users/channing/tmp/280_port/lift-base/lift-actor/src/main/scala/net/liftweb/actor/LiftActor.scala:216:
error: type mismatch;
found : net.liftweb.actor.MsgWithResp
required: T
this ! MsgWithResp(msg, future)
^
/Users/channing/tmp/280_port/lift-base/lift-actor/src/main/scala/net/liftweb/actor/LiftActor.scala:229:
error: type mismatch;
found : net.liftweb.actor.MsgWithResp
required: T
this ! MsgWithResp(msg, future)
^
/Users/channing/tmp/280_port/lift-base/lift-actor/src/main/scala/net/liftweb/actor/LiftActor.scala:235:
error: type mismatch;
found : net.liftweb.actor.MsgWithResp
required: T
this ! MsgWithResp(msg, future)
^
8 errors found
--
View this message in context:
http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26862327.html
Sent from the liftweb mailing list archive at Nabble.com.
--
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] Re: [scala-internals] RC4 candidate for the first 2.8.0 beta
Lift built against RC3, but with RC4 we get this error: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.scala_tools.maven.executions.MainHelper.runMain(MainHelper.java:151) at org.scala_tools.maven.executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26) Caused by: java.lang.AssertionError: assertion failed: type error: can't convert from REFERENCE(net.liftweb.util.StringHelpers) to REFERENCE(net.liftweb.util.BasicTypesHelpers) in unit BasicTypesHelpers.scala at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:943) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:927) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadLabelArguments(GenICode.scala:990) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:710) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:484) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:850) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:130) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:152) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:106) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:83) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:79) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.reporters.Reporter.withSource(Reporter.scala:48) at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.collection.Iterator$class.foreach(Iterator.scala:582) at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:285) at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:259) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:72) at scala.tools.nsc.Global$Run.compileSources(Global.scala:749) at scala.tools.nsc.Global$Run.compile(Global.scala:839) at scala.tools.nsc.Main$.process(Main.scala:109) at scala.tools.nsc.Main$.main(Main.scala:123) at scala.tools.nsc.Main.main(Main.scala) ... 6 more Heiko 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
Re: [Lift] Re: Re: [lift] Building Lift with scala 2.8.0
2009/12/20 Channing Walton channingwal...@mac.com ok here it is. The only thing I changed in the main pom is the scala version to the 2.8.0 beta rc3 If you are using the latest version of the 280_port branch there is no need to change the scala version = It is already 2.8 Beta RC4. Maybe you are using some outdated branch? Heiko 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.
[Lift] Re: [scala-internals] RC4 candidate for the first 2.8.0 beta
Thanks for letting us know. This looks like something stirred up by the change in erasure. We'll investigate Monday what it is. Cheers -- Martin On Sun, Dec 20, 2009 at 11:43 AM, Heiko Seeberger heiko.seeber...@googlemail.com wrote: Lift built against RC3, but with RC4 we get this error: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.scala_tools.maven.executions.MainHelper.runMain(MainHelper.java:151) at org.scala_tools.maven.executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26) Caused by: java.lang.AssertionError: assertion failed: type error: can't convert from REFERENCE(net.liftweb.util.StringHelpers) to REFERENCE(net.liftweb.util.BasicTypesHelpers) in unit BasicTypesHelpers.scala at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:943) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:927) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadLabelArguments(GenICode.scala:990) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:710) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:484) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:850) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:130) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:152) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:106) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:83) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:79) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.reporters.Reporter.withSource(Reporter.scala:48) at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.collection.Iterator$class.foreach(Iterator.scala:582) at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:285) at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:259) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:72) at scala.tools.nsc.Global$Run.compileSources(Global.scala:749) at scala.tools.nsc.Global$Run.compile(Global.scala:839) at scala.tools.nsc.Main$.process(Main.scala:109) at scala.tools.nsc.Main$.main(Main.scala:123) at scala.tools.nsc.Main.main(Main.scala) ... 6 more Heiko My job: weiglewilczek.com My blog: heikoseeberger.name Follow me:
[Lift] Re: How can i get the user IP address in the lift ?
OK, Got it. Thank guys! Thanks for these useful information! Cheers, Neil On Dec 20, 5:38 pm, Timothy Perrett timo...@getintheloop.eu wrote: Personally, i'd drop the lambda, and do: S.containerRequest.map(_.remoteAddress).openOr(localhost) the map returns a Box[String], so we can get access and provide a handy default if need be. If you dont want that, just do a pattern match or whatever you want. Cheers, Tim On Dec 20, 2:38 am, Jarod Liu liuyuan...@gmail.com wrote: S.containerRequest.map(r=println(r.remoteAddress)) On Dec 20, 4:18 am, Neil.Lv anim...@gmail.com wrote: Hi all, I want to get the IP address of the users. How can i get the remote IP address in the lift? Thanks for any suggestion! Cheers, Neil -- 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] [lift] Building Lift with scala 2.8.0
Your git stuff was quite OK, the Problem was that the branch is 280_port and not vice versa ;-) Please try it again: git clone ... git branch 280_port origin/280_port git checkout 280_port Heiko On Sunday, December 20, 2009, Channing Walton channingwal...@mac.com wrote: ah I see the problem - I know nothing about git! I original thought that the URL at the top of the github page for port_280 would get me port_280 which it doesn't. I tried following the instructions here: http://wiki.github.com/bricoleurs/bricolage/working-with-branches But that isn't working for me: % git clone git://github.com/dpp/liftweb.git ... % cd liftweb/ % git fetch origin % git checkout --track -b port_280 origin/port_280 fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/port_280' which can not be resolved as commit? What should I do? (I've trawled gits help pages but I'm not having any luck) Channing -- View this message in context: http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26862689.html Sent from the liftweb mailing list archive at Nabble.com. -- 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.
[Lift] Re: [lift] Building Lift with scala 2.8.0
thanks that worked! Onwards ... Heiko Seeberger-4 wrote: Your git stuff was quite OK, the Problem was that the branch is 280_port and not vice versa ;-) Please try it again: git clone ... git branch 280_port origin/280_port git checkout 280_port Heiko On Sunday, December 20, 2009, Channing Walton channingwal...@mac.com wrote: ah I see the problem - I know nothing about git! I original thought that the URL at the top of the github page for port_280 would get me port_280 which it doesn't. I tried following the instructions here: http://wiki.github.com/bricoleurs/bricolage/working-with-branches But that isn't working for me: % git clone git://github.com/dpp/liftweb.git ... % cd liftweb/ % git fetch origin % git checkout --track -b port_280 origin/port_280 fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/port_280' which can not be resolved as commit? What should I do? (I've trawled gits help pages but I'm not having any luck) Channing -- View this message in context: http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26862689.html Sent from the liftweb mailing list archive at Nabble.com. -- 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. -- View this message in context: http://old.nabble.com/Building-Lift-with-scala-2.8.0-tp26858625p26864477.html Sent from the liftweb mailing list archive at Nabble.com. -- 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] Re: Documentation Site
Hi Tim, Thanks for your reply. 1.0 is the last official release that was not a milestone or snapshot - thus, they are the primary api docs right now until we release 2.0 (that is, what was being called 1.1 is being renamed to 2.0). API docs are a process issue, and handled as part of our build process - they will always live both on scala-tools and liftweb.net where applicable. They wont ever sit anywhere else (officially). I just mentioned the API docs, because some time ago I was on the look for something I couldn't find in the 1.0 docs and than I had real problems to find the link for the 1.1 docs. Yes, the wiki is a little out dated. I forget the number of times i've tried to spear head a wiki effort... the bottom line is that other people need to start writing content - there are a fair number of competent lift users in the community who simply are not giving anything back by way of articles or wiki cleaning - thus our docs get out dated fast because the team prefer to write code than documentation. We even tried to appointed a wiki gardener but he appears to have just disappeared into the ether... Id be open to hearing suggestions on how one could keep the wiki more up to date? Short of users actually contributing back, there is a limit on what the team can do at anyone time. We are getting there, but its not going to be an overnight process. Actually I didn't used the Lift Wiki so much, because in general I don't like the Media Wiki content organization so much. I think (my personal opinion) there are to much links and sometimes its hard to see which ones belong to the Media Wiki functionality itself and which ones are actually representing the interesting stuff. I think this was one of the major reasons why I didn't applied as a Wiki gardener. Blogs - a fundamental corner stone of the internet and your right, they are a great information repository. Perhaps we could syndicate some blogs onto liftweb.net during the rewrite (yes, im going to rewrite it at last!)... certainly open for that. Maybe some idea would be to setup liftweb.net with some CMS and first re-arrange and update the content there and than, as a second run, include Blogs, the Wiki and easy to find links for the API docs. Besides that, another problem with Media Wiki is, that it doesn't provide all the functionality, that this project needs and because of this, at least one other application is needed to deal with the rest. A CMS can do a lot and there are a lot of plug-ins available for all kinds of stuff (a lot of stuff that doesn't need to be re-invented). And I believe that one system is easier to handle than three different ones. Like I said before, just my opinion and an idea. Cheers, Tim PS: Sorry that was a bit of a rant, but this is a frustrating issue that i've been pushing for over a year ;-) thanks. On Dec 19, 1:16 pm, Hannes hannes.flo...@gmx.li wrote: Definitely! I would like one location for everything, but I believe that the current situation is not like that. - there two API docs 1.0 and 1.1, the latter is hard to find - there's liftweb.net (a little bit out-dated) - there's the Wiki - there's David's Blog (that has some unique information) What did I forget? thanks. Why not improve the existing wiki on github? Or fork the book and make improvements that way? I'm not opposed to additional resources, but why create another place where docs may or not be out of date? I think that Lift is still at the point where one location of docs is better. My opinion. On Dec 19, 6:37 am, Hannes hannes.flo...@gmx.li wrote: Hi Lifters, I'm thinking about setting up a site that takes together all available information about Lift (Links, News, ...). I would like to know, if this would be appreciated or not. I still think that all the available information is to much spread out - specially for people who get started with Lift. In case of positive responds, I would like to setup a Plone (CMS) site. I think its a really good tool, to organize content. thanks for listening. -- 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 athttp://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 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. -- You received this message because you are subscribed to the Google Groups Lift group. To post to
[Lift] Tip for lift-textile syntax
In case I'm not the only one spending quite a few minutes to find out about the (great!) textile plugin syntax - see this: http://scala-tools.org/scaladocs/liftweb/1.0/net/liftweb/textile/TextileParser.scala.html (scroll down to line 1008) Cheers, stephanos -- 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] **Important** Announcing the Lift 2.0 branch
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 -- 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] The future of lift-core
Folks, lift-core is a 'meta' project that can be added as a dependency to a Lift project to pull in all the Lift modules. This serves as a singular configuration point in a Lift based application. However, since lift-core downloads all the Lift modules (irrespective of whether the project needs it), adding this as the dependency slow down things for a standard project that doesn't need some additional modules. In a sense, we have moved quite a bit from the initial purpose of having single dependency on this 'meta' project in a Lift application. Further, the name is a misnomer now! The question, therefore is: Should we consider deprecating this? If not, we need to document when it should be preferred and when not. If yes, what should be the time frame for making the move? With Lift 2.0 coming up, now might be a good time to make a decision. Thoughts? Cheers, Indrajit NB: An open question to anybody in the Lift: Who among you are actually using lift-core in you project and what is the level of impact you foresee in case you have to move on to have an alternative approach. -- 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] Directory structure
While we're discussing lift-core in a separate thread, I wanted to bring up a minor annoyance All module directories in the repository start with lift-, boisv...@smudge:~/git/liftweb$ tree -L 2 | grep lift |-- lift-archetypes | |-- lift-archetype-basic | |-- lift-archetype-blank | |-- lift-archetype-jpa-basic | |-- lift-archetype-jpa-blank | |-- lift-archetype-jpa-blank-single |-- lift-base | |-- lift-actor | |-- lift-common | |-- lift-json | |-- lift-util | |-- lift-webkit |-- lift-core |-- lift-examples | |-- hellolift |-- lift-misc | |-- lift-installer |-- lift-modules | |-- lift-amqp | |-- lift-facebook | |-- lift-jta | |-- lift-machine | |-- lift-oauth | |-- lift-openid | |-- lift-osgi | |-- lift-paypal | |-- lift-testkit | |-- lift-textile | |-- lift-widgets | |-- lift-wizard | |-- lift-xmpp |-- lift-persistence | |-- lift-jpa | |-- lift-mapper | |-- lift-record This naming isn't very practical when navigating the directory structure since it meddles with completion. e.g. cd TAB (beep!) lift- TAB (beep!) c TAB (finally completes core) Does Maven support simpler names? Could we have something like this? |-- base | |-- actor | |-- common | |-- json | |-- util | |-- webkit |-- modules | |-- amqp | |-- ... | |-- ... (I'm not suggesting change the names of the modules; just the names of the directories) alex -- 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] Directory structure
Alex, Yes, it's possible to have artifactId ≠ directoryName for Maven projects. But last time I did this Maven chose to be very cruel with me (site generation, relative path resolutions etc. broke). Also see the point and convergence to decision here: http://groups.google.com/group/liftweb/msg/73a5652a55076384 In this case, I would usually type out cd liftcore blindly and the right thing would happen automatically thanks to shopt -s cdspell in my .bashrc config. But I digress. However, I won't mind re-opening this discussion on 'lift-' prefix if you want me to. Cheers, Indrajit On 21/12/09 1:29 AM, Alex Boisvert wrote: While we're discussing lift-core in a separate thread, I wanted to bring up a minor annoyance All module directories in the repository start with lift-, boisv...@smudge:~/git/liftweb$ tree -L 2 | grep lift |-- lift-archetypes | |-- lift-archetype-basic | |-- lift-archetype-blank | |-- lift-archetype-jpa-basic | |-- lift-archetype-jpa-blank | |-- lift-archetype-jpa-blank-single |-- lift-base | |-- lift-actor | |-- lift-common | |-- lift-json | |-- lift-util | |-- lift-webkit |-- lift-core |-- lift-examples | |-- hellolift |-- lift-misc | |-- lift-installer |-- lift-modules | |-- lift-amqp | |-- lift-facebook | |-- lift-jta | |-- lift-machine | |-- lift-oauth | |-- lift-openid | |-- lift-osgi | |-- lift-paypal | |-- lift-testkit | |-- lift-textile | |-- lift-widgets | |-- lift-wizard | |-- lift-xmpp |-- lift-persistence | |-- lift-jpa | |-- lift-mapper | |-- lift-record This naming isn't very practical when navigating the directory structure since it meddles with completion. e.g. cd TAB (beep!) lift- TAB (beep!) c TAB (finally completes core) Does Maven support simpler names? Could we have something like this? |-- base | |-- actor | |-- common | |-- json | |-- util | |-- webkit |-- modules | |-- amqp | |-- ... | |-- ... (I'm not suggesting change the names of the modules; just the names of the directories) alex -- 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. -- 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] Re: CMS or wiki built with Lift?
Well, as far as CMS Glenn is working on one here http://github.com/glennSilverman/democritus and David is starting one here http://github.com/dpp/hoisted On Dec 21, 7:24 am, jlist9 jli...@gmail.com wrote: Hi, I haven't found anything when I searched but I'd like to double check here - is there an open source CMS (content management system) or wiki system built with Lift? I need to update a simple site and I'm hoping that I can learn Lift by examples. -- 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] Directory structure
I don't think it's worth a lot of effort. If it's been tried and doesn't work nicely, I'm fine with sticking with the current structure. At some point, though, you have to decide who's boss, you or the build system ;) (I love taking jabs at Maven, sorry) alex On Sun, Dec 20, 2009 at 12:42 PM, Indrajit Raychaudhuri indraj...@gmail.com wrote: Alex, Yes, it's possible to have artifactId ≠ directoryName for Maven projects. But last time I did this Maven chose to be very cruel with me (site generation, relative path resolutions etc. broke). Also see the point and convergence to decision here: http://groups.google.com/group/liftweb/msg/73a5652a55076384 In this case, I would usually type out cd liftcore blindly and the right thing would happen automatically thanks to shopt -s cdspell in my .bashrc config. But I digress. However, I won't mind re-opening this discussion on 'lift-' prefix if you want me to. Cheers, Indrajit On 21/12/09 1:29 AM, Alex Boisvert wrote: While we're discussing lift-core in a separate thread, I wanted to bring up a minor annoyance All module directories in the repository start with lift-, boisv...@smudge:~/git/liftweb$ tree -L 2 | grep lift |-- lift-archetypes | |-- lift-archetype-basic | |-- lift-archetype-blank | |-- lift-archetype-jpa-basic | |-- lift-archetype-jpa-blank | |-- lift-archetype-jpa-blank-single |-- lift-base | |-- lift-actor | |-- lift-common | |-- lift-json | |-- lift-util | |-- lift-webkit |-- lift-core |-- lift-examples | |-- hellolift |-- lift-misc | |-- lift-installer |-- lift-modules | |-- lift-amqp | |-- lift-facebook | |-- lift-jta | |-- lift-machine | |-- lift-oauth | |-- lift-openid | |-- lift-osgi | |-- lift-paypal | |-- lift-testkit | |-- lift-textile | |-- lift-widgets | |-- lift-wizard | |-- lift-xmpp |-- lift-persistence | |-- lift-jpa | |-- lift-mapper | |-- lift-record This naming isn't very practical when navigating the directory structure since it meddles with completion. e.g. cd TAB (beep!) lift- TAB (beep!) c TAB (finally completes core) Does Maven support simpler names? Could we have something like this? |-- base | |-- actor | |-- common | |-- json | |-- util | |-- webkit |-- modules | |-- amqp | |-- ... | |-- ... (I'm not suggesting change the names of the modules; just the names of the directories) alex -- 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. -- 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. -- 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] Directory structure
On 21/12/09 2:18 AM, Alex Boisvert wrote: I don't think it's worth a lot of effort. If it's been tried and doesn't work nicely, I'm fine with sticking with the current structure. At some point, though, you have to decide who's boss, you or the build system ;) (I love taking jabs at Maven, sorry) So do I, no worries. Ironically, Maven is still getting away with all these! - IRC alex On Sun, Dec 20, 2009 at 12:42 PM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.com wrote: Alex, Yes, it's possible to have artifactId ≠ directoryName for Maven projects. But last time I did this Maven chose to be very cruel with me (site generation, relative path resolutions etc. broke). Also see the point and convergence to decision here: http://groups.google.com/group/liftweb/msg/73a5652a55076384 In this case, I would usually type out cd liftcore blindly and the right thing would happen automatically thanks to shopt -s cdspell in my .bashrc config. But I digress. However, I won't mind re-opening this discussion on 'lift-' prefix if you want me to. Cheers, Indrajit On 21/12/09 1:29 AM, Alex Boisvert wrote: While we're discussing lift-core in a separate thread, I wanted to bring up a minor annoyance All module directories in the repository start with lift-, boisv...@smudge:~/git/liftweb$ tree -L 2 | grep lift |-- lift-archetypes | |-- lift-archetype-basic | |-- lift-archetype-blank | |-- lift-archetype-jpa-basic | |-- lift-archetype-jpa-blank | |-- lift-archetype-jpa-blank-single |-- lift-base | |-- lift-actor | |-- lift-common | |-- lift-json | |-- lift-util | |-- lift-webkit |-- lift-core |-- lift-examples | |-- hellolift |-- lift-misc | |-- lift-installer |-- lift-modules | |-- lift-amqp | |-- lift-facebook | |-- lift-jta | |-- lift-machine | |-- lift-oauth | |-- lift-openid | |-- lift-osgi | |-- lift-paypal | |-- lift-testkit | |-- lift-textile | |-- lift-widgets | |-- lift-wizard | |-- lift-xmpp |-- lift-persistence | |-- lift-jpa | |-- lift-mapper | |-- lift-record This naming isn't very practical when navigating the directory structure since it meddles with completion. e.g. cd TAB (beep!) lift- TAB (beep!) c TAB (finally completes core) Does Maven support simpler names? Could we have something like this? |-- base | |-- actor | |-- common | |-- json | |-- util | |-- webkit |-- modules | |-- amqp | |-- ... | |-- ... (I'm not suggesting change the names of the modules; just the names of the directories) alex -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com mailto:liftweb@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com mailto:liftweb%2bunsubscr...@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 liftweb@googlegroups.com mailto:liftweb@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com mailto:liftweb%2bunsubscr...@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 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. -- 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] Re: CMS or wiki built with Lift?
Thanks! No checkins for hoisted yet. I'll check out Democritus. On Sun, Dec 20, 2009 at 12:44 PM, Randinn rand...@gmail.com wrote: Well, as far as CMS Glenn is working on one here http://github.com/glennSilverman/democritus and David is starting one here http://github.com/dpp/hoisted On Dec 21, 7:24 am, jlist9 jli...@gmail.com wrote: Hi, I haven't found anything when I searched but I'd like to double check here - is there an open source CMS (content management system) or wiki system built with Lift? I need to update a simple site and I'm hoping that I can learn Lift by examples. -- 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. -- 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] Re: Documentation Site
To give the benefit of doubt to people who use Lift knowing that is closed to commiting they may think the same about the documentation. I have added a bit but I've more thrown up a few pages and figured someone with more knowledge would flesh them out. On Dec 20, 8:47 pm, Timothy Perrett timo...@getintheloop.eu wrote: 1.0 is the last official release that was not a milestone or snapshot - thus, they are the primary api docs right now until we release 2.0 (that is, what was being called 1.1 is being renamed to 2.0). API docs are a process issue, and handled as part of our build process - they will always live both on scala-tools and liftweb.net where applicable. They wont ever sit anywhere else (officially). Yes, the wiki is a little out dated. I forget the number of times i've tried to spear head a wiki effort... the bottom line is that other people need to start writing content - there are a fair number of competent lift users in the community who simply are not giving anything back by way of articles or wiki cleaning - thus our docs get out dated fast because the team prefer to write code than documentation. We even tried to appointed a wiki gardener but he appears to have just disappeared into the ether... Id be open to hearing suggestions on how one could keep the wiki more up to date? Short of users actually contributing back, there is a limit on what the team can do at anyone time. We are getting there, but its not going to be an overnight process. Blogs - a fundamental corner stone of the internet and your right, they are a great information repository. Perhaps we could syndicate some blogs onto liftweb.net during the rewrite (yes, im going to rewrite it at last!)... certainly open for that. Cheers, Tim PS: Sorry that was a bit of a rant, but this is a frustrating issue that i've been pushing for over a year ;-) On Dec 19, 1:16 pm, Hannes hannes.flo...@gmx.li wrote: Definitely! I would like one location for everything, but I believe that the current situation is not like that. - there two API docs 1.0 and 1.1, the latter is hard to find - there's liftweb.net (a little bit out-dated) - there's the Wiki - there's David's Blog (that has some unique information) What did I forget? thanks. Why not improve the existing wiki on github? Or fork the book and make improvements that way? I'm not opposed to additional resources, but why create another place where docs may or not be out of date? I think that Lift is still at the point where one location of docs is better. My opinion. On Dec 19, 6:37 am, Hannes hannes.flo...@gmx.li wrote: Hi Lifters, I'm thinking about setting up a site that takes together all available information about Lift (Links, News, ...). I would like to know, if this would be appreciated or not. I still think that all the available information is to much spread out - specially for people who get started with Lift. In case of positive responds, I would like to setup a Plone (CMS) site. I think its a really good tool, to organize content. thanks for listening. -- 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 athttp://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 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] Re: Documentation Site
I really don't think thats the issue - Lift is not closed to committing... if that were the case, David would never have recruited us onto the team ;-) 95% of all OSS projects i've ever come across have the same policy when it comes to wikis etc... they are organic, community driven beasts. For instance, I was no aware that you had written any articles... but that is great. You say you want them fleshed out? In what way / what information do you need. Writing documentation is actually a great way to understand something because it means you have to fully grok it in order to teach others - we need to solve the documentation issue for sure, and any contribution you or others have is very much welcome. Cheers, Tim On 20 Dec 2009, at 21:43, Randinn wrote: To give the benefit of doubt to people who use Lift knowing that is closed to commiting they may think the same about the documentation. I have added a bit but I've more thrown up a few pages and figured someone with more knowledge would flesh them out. On Dec 20, 8:47 pm, Timothy Perrett timo...@getintheloop.eu wrote: 1.0 is the last official release that was not a milestone or snapshot - thus, they are the primary api docs right now until we release 2.0 (that is, what was being called 1.1 is being renamed to 2.0). API docs are a process issue, and handled as part of our build process - they will always live both on scala-tools and liftweb.net where applicable. They wont ever sit anywhere else (officially). Yes, the wiki is a little out dated. I forget the number of times i've tried to spear head a wiki effort... the bottom line is that other people need to start writing content - there are a fair number of competent lift users in the community who simply are not giving anything back by way of articles or wiki cleaning - thus our docs get out dated fast because the team prefer to write code than documentation. We even tried to appointed a wiki gardener but he appears to have just disappeared into the ether... Id be open to hearing suggestions on how one could keep the wiki more up to date? Short of users actually contributing back, there is a limit on what the team can do at anyone time. We are getting there, but its not going to be an overnight process. Blogs - a fundamental corner stone of the internet and your right, they are a great information repository. Perhaps we could syndicate some blogs onto liftweb.net during the rewrite (yes, im going to rewrite it at last!)... certainly open for that. Cheers, Tim PS: Sorry that was a bit of a rant, but this is a frustrating issue that i've been pushing for over a year ;-) On Dec 19, 1:16 pm, Hannes hannes.flo...@gmx.li wrote: Definitely! I would like one location for everything, but I believe that the current situation is not like that. - there two API docs 1.0 and 1.1, the latter is hard to find - there's liftweb.net (a little bit out-dated) - there's the Wiki - there's David's Blog (that has some unique information) What did I forget? thanks. Why not improve the existing wiki on github? Or fork the book and make improvements that way? I'm not opposed to additional resources, but why create another place where docs may or not be out of date? I think that Lift is still at the point where one location of docs is better. My opinion. On Dec 19, 6:37 am, Hannes hannes.flo...@gmx.li wrote: Hi Lifters, I'm thinking about setting up a site that takes together all available information about Lift (Links, News, ...). I would like to know, if this would be appreciated or not. I still think that all the available information is to much spread out - specially for people who get started with Lift. In case of positive responds, I would like to setup a Plone (CMS) site. I think its a really good tool, to organize content. thanks for listening. -- 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 athttp://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 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. -- 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] Re: Directory structure
Agreed. Its annoying, but right now I think we are probably stuck with it. Cheers, Tim On Dec 20, 9:06 pm, Indrajit Raychaudhuri indraj...@gmail.com wrote: On 21/12/09 2:18 AM, Alex Boisvert wrote: I don't think it's worth a lot of effort. If it's been tried and doesn't work nicely, I'm fine with sticking with the current structure. At some point, though, you have to decide who's boss, you or the build system ;) (I love taking jabs at Maven, sorry) So do I, no worries. Ironically, Maven is still getting away with all these! - IRC alex On Sun, Dec 20, 2009 at 12:42 PM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.com wrote: Alex, Yes, it's possible to have artifactId ≠ directoryName for Maven projects. But last time I did this Maven chose to be very cruel with me (site generation, relative path resolutions etc. broke). Also see the point and convergence to decision here: http://groups.google.com/group/liftweb/msg/73a5652a55076384 In this case, I would usually type out cd liftcore blindly and the right thing would happen automatically thanks to shopt -s cdspell in my .bashrc config. But I digress. However, I won't mind re-opening this discussion on 'lift-' prefix if you want me to. Cheers, Indrajit On 21/12/09 1:29 AM, Alex Boisvert wrote: While we're discussing lift-core in a separate thread, I wanted to bring up a minor annoyance All module directories in the repository start with lift-, boisv...@smudge:~/git/liftweb$ tree -L 2 | grep lift |-- lift-archetypes | |-- lift-archetype-basic | |-- lift-archetype-blank | |-- lift-archetype-jpa-basic | |-- lift-archetype-jpa-blank | |-- lift-archetype-jpa-blank-single |-- lift-base | |-- lift-actor | |-- lift-common | |-- lift-json | |-- lift-util | |-- lift-webkit |-- lift-core |-- lift-examples | |-- hellolift |-- lift-misc | |-- lift-installer |-- lift-modules | |-- lift-amqp | |-- lift-facebook | |-- lift-jta | |-- lift-machine | |-- lift-oauth | |-- lift-openid | |-- lift-osgi | |-- lift-paypal | |-- lift-testkit | |-- lift-textile | |-- lift-widgets | |-- lift-wizard | |-- lift-xmpp |-- lift-persistence | |-- lift-jpa | |-- lift-mapper | |-- lift-record This naming isn't very practical when navigating the directory structure since it meddles with completion. e.g. cd TAB (beep!) lift- TAB (beep!) c TAB (finally completes core) Does Maven support simpler names? Could we have something like this? |-- base | |-- actor | |-- common | |-- json | |-- util | |-- webkit |-- modules | |-- amqp | |-- ... | |-- ... (I'm not suggesting change the names of the modules; just the names of the directories) alex -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com mailto:liftweb@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com mailto:liftweb%2bunsubscr...@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 liftweb@googlegroups.com mailto:liftweb@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com mailto:liftweb%2bunsubscr...@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 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. -- 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] PayPal X
Guys, Is their any appetite for adding support for the new Paypal X services? https://www.x.com/index.jspa Basically it allows you to seamlessly integrate the billing cycle without transferring to paypal I personally dont have a burning need, but im thinking it would be a cool extension to the paypal module. Cheers, Tim -- 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] **Important** Announcing the Lift 2.0 branch
Why not release Lift2.0 with Scala2.8? On Mon, Dec 21, 2009 at 3:34 AM, Indrajit Raychaudhuri indraj...@gmail.comwrote: 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 -- 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. -- Scala中文社区: http://groups.google.com/group/scalacn -- 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] Re: **Important** Announcing the Lift 2.0 branch
Why not with 2.8 just going to beta 2.0 my estimation is that 2.0 will be finished before On Dec 21, 12:03 pm, Xuefeng Wu ben...@gmail.com wrote: Why not release Lift2.0 with Scala2.8? On Mon, Dec 21, 2009 at 3:34 AM, Indrajit Raychaudhuri indraj...@gmail.comwrote: 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 athttp://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/450a3e741... [2]http://wiki.github.com/dpp/liftweb/committer-release-process Feedbacks most 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. -- Scala中文社区: http://groups.google.com/group/scalacn -- 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,
[Lift] Paranamer? Missing com.thoughtworks.paranamer:paranamer:jar:2.0
Say, what’s this paranamer? Are we meant to build it and manually install it in our local repositories? Missing: -- 1) com.thoughtworks.paranamer:paranamer:jar:2.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.thoughtworks.paranamer - DartifactId=paranamer -Dversion=2.0 -Dpackaging=jar -Dfile=/path/to/ file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.thoughtworks.paranamer - DartifactId=paranamer -Dversion=2.0 -Dpackaging=jar -Dfile=/path/to/ file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.esme:esme-server:war:0.3.0-SNAPSHOT 2) net.liftweb:lift-mapper:jar:1.1-SNAPSHOT 3) net.liftweb:lift-json:jar:1.1-SNAPSHOT 4) com.thoughtworks.paranamer:paranamer:jar:2.0 -- 1 required artifact is missing. for artifact: org.apache.esme:esme-server:war:0.3.0-SNAPSHOT from the specified remote repositories: scala-stats (http://www.lag.net/nest), compass-project.org (http://repo.compass-project.org), scala-tools.org (http://scala-tools.org/repo-releases), opendmk (http://maven.tigase.org/), configgy (http://www.lag.net/repo), scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots), central (http://repo1.maven.org/maven2) -- 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] Re: **Important** Announcing the Lift 2.0 branch
I mean that lift1.1 and lift2.0 may have the same futures, But lift1.1 is for Scala2.7 and lift2.0 is for Scala2.8. With Scala2.8 stable , the lift1.1 could not be enhanced. It's better than Lift2.0-Scala2.7 and Lift2.0-Scala2.8. And there're better explain why Lift2.0 and Lift1.1 if people ask what's the different between Lift2.0 and Lift1.1? On Mon, Dec 21, 2009 at 9:31 AM, Randinn rand...@gmail.com wrote: Why not with 2.8 just going to beta 2.0 my estimation is that 2.0 will be finished before On Dec 21, 12:03 pm, Xuefeng Wu ben...@gmail.com wrote: Why not release Lift2.0 with Scala2.8? On Mon, Dec 21, 2009 at 3:34 AM, Indrajit Raychaudhuri indraj...@gmail.comwrote: 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 athttp://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/450a3e741. .. [2]http://wiki.github.com/dpp/liftweb/committer-release-process Feedbacks most 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.
Re: [Lift] Paranamer? Missing com.thoughtworks.paranamer:paranamer:jar:2.0
For paranamer, check out: http://paranamer.codehaus.org It's indeed available in the central repo: http://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer I think this might have been due to the repo being blacklisted because of a previous failed connection. Cheers, Indrajit On 21/12/09 7:45 AM, Dave Briccetti wrote: Say, what’s this paranamer? Are we meant to build it and manually install it in our local repositories? Missing: -- 1) com.thoughtworks.paranamer:paranamer:jar:2.0 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.thoughtworks.paranamer - DartifactId=paranamer -Dversion=2.0 -Dpackaging=jar -Dfile=/path/to/ file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.thoughtworks.paranamer - DartifactId=paranamer -Dversion=2.0 -Dpackaging=jar -Dfile=/path/to/ file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.esme:esme-server:war:0.3.0-SNAPSHOT 2) net.liftweb:lift-mapper:jar:1.1-SNAPSHOT 3) net.liftweb:lift-json:jar:1.1-SNAPSHOT 4) com.thoughtworks.paranamer:paranamer:jar:2.0 -- 1 required artifact is missing. for artifact: org.apache.esme:esme-server:war:0.3.0-SNAPSHOT from the specified remote repositories: scala-stats (http://www.lag.net/nest), compass-project.org (http://repo.compass-project.org), scala-tools.org (http://scala-tools.org/repo-releases), opendmk (http://maven.tigase.org/), configgy (http://www.lag.net/repo), scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots), central (http://repo1.maven.org/maven2) -- 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. -- 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] Re: **Important** Announcing the Lift 2.0 branch
Eventually, yes, Lift 2.0 would be on Scala 2.8. But that's not the only difference between Lift 1.0 and Lift 2.0. To follow the context, you might want to take a look at this thread: http://groups.google.com/group/liftweb/browse_thread/thread/479edef7700ccce6. Cheers, Indrajit On 21/12/09 8:22 AM, Xuefeng Wu wrote: I mean that lift1.1 and lift2.0 may have the same futures, But lift1.1 is for Scala2.7 and lift2.0 is for Scala2.8. With Scala2.8 stable , the lift1.1 could not be enhanced. It's better than Lift2.0-Scala2.7 and Lift2.0-Scala2.8. And there're better explain why Lift2.0 and Lift1.1 if people ask what's the different between Lift2.0 and Lift1.1? On Mon, Dec 21, 2009 at 9:31 AM, Randinn rand...@gmail.com mailto:rand...@gmail.com wrote: Why not with 2.8 just going to beta 2.0 my estimation is that 2.0 will be finished before On Dec 21, 12:03 pm, Xuefeng Wu ben...@gmail.com mailto:ben...@gmail.com wrote: Why not release Lift2.0 with Scala2.8? On Mon, Dec 21, 2009 at 3:34 AM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.comwrote: 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 athttp://dev.liftweb.net 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
Re: [Lift] Directory structure
Le 20/12/2009 20:59, Alex Boisvert a écrit : [...] e.g. cd TAB (beep!) lift- TAB (beep!) c TAB (finally completes core) Or just use a modern shell, like ZSH : In liftweb: % cd lTABift-TAB lift-archetypes/ lift-core/lift-misc/ lift-base/lift-examples/lift-modules/ % cd lift-cTABore/ etc. There is a good configuration available here : http://svn.asyd.net/svn/zsh/trunk As the readme suggest, you just have to do that to start to understand what a wonderfull shell is: 8--- % cd % svn checkout http://svn.asyd.net/svn/zsh/trunk .zsh % ln -s .zsh/zshrc .zshrc 8--- Enjoy :) -- Francois Armand http://fanf42.blogspot.com -- 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] Re: **Important** Announcing the Lift 2.0 branch
That's great that Lift2.0 is on Scala 2.8 On Mon, Dec 21, 2009 at 1:17 PM, Indrajit Raychaudhuri indraj...@gmail.comwrote: Eventually, yes, Lift 2.0 would be on Scala 2.8. But that's not the only difference between Lift 1.0 and Lift 2.0. To follow the context, you might want to take a look at this thread: http://groups.google.com/group/liftweb/browse_thread/thread/479edef7700ccce6 . Cheers, Indrajit On 21/12/09 8:22 AM, Xuefeng Wu wrote: I mean that lift1.1 and lift2.0 may have the same futures, But lift1.1 is for Scala2.7 and lift2.0 is for Scala2.8. With Scala2.8 stable , the lift1.1 could not be enhanced. It's better than Lift2.0-Scala2.7 and Lift2.0-Scala2.8. And there're better explain why Lift2.0 and Lift1.1 if people ask what's the different between Lift2.0 and Lift1.1? On Mon, Dec 21, 2009 at 9:31 AM, Randinn rand...@gmail.com mailto:rand...@gmail.com wrote: Why not with 2.8 just going to beta 2.0 my estimation is that 2.0 will be finished before On Dec 21, 12:03 pm, Xuefeng Wu ben...@gmail.com mailto:ben...@gmail.com wrote: Why not release Lift2.0 with Scala2.8? On Mon, Dec 21, 2009 at 3:34 AM, Indrajit Raychaudhuri indraj...@gmail.com mailto:indraj...@gmail.comwrote: 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 athttp://dev.liftweb.net 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
[Lift] Validation errors shown on CRUDify models?
Are validation errors shown on CRUDify create/edit pages?
I have validators set up like this:
object subdomain extends MappedString(this,64) {
override def validations = List(valUnique(Subdomain taken.)_,
valRegex(Pattern.compile(^[A-Za-z0-9-]*$),
Subdomains must only contain
letters, numbers, and
hyphens.
)_) ::: super.validations
override def displayName = Subdomain
override def dbIndexed_? = true
}
And on an invalid entry, the form will just silently fail - that is,
when submitted, it will just give back the exact same form state - no
error messages, no changes in the filled-out entries. This confuses me.
--
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] The future of lift-core
2009/12/20 Indrajit Raychaudhuri indraj...@gmail.com lift-core is a 'meta' project that can be added as a dependency to a Lift project to pull in all the Lift modules. This serves as a singular configuration point in a Lift based application. However, since lift-core downloads all the Lift modules (irrespective of whether the project needs it), adding this as the dependency slow down things for a standard project that doesn't need some additional modules. From a modularity standpoint pulling in all the numerous Lift modules - some of them very special - is a bad idea. Further, the name is a misnomer now! Yes, it is totally misleading. The question, therefore is: Should we consider deprecating this? Yes! If yes, what should be the time frame for making the move? Perfect fit for 2.0. Heiko 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.
