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
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,
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
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
--
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
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
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._
^
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
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
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:
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
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
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,
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
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
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
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
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
| |--
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:
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
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
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
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
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
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.
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
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
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
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,
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
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
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
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
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
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
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-]*$),
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
37 matches
Mail list logo
