[Lift] Re: WebSockets are Coming

[Marius]

I think Lift Ajax support should also use Web-Sockets when detected.
It should be fairly straight forward to add support for web-sockets
since our client Ajax support is abstracted by JsArtifacts trait. I
think Jetty 7 supports web-sockets (well an early implementation
http://blogs.webtide.com/gregw/entry/jetty_websocket_server). So
having Chronium and Jetty 7 we should be able to try it out but from
Comet perspective we do not support yet Jetty 7 Continuations. This is
related with defect http://github.com/dpp/liftweb/issues/#issue/217
that I need to start working on as well.

I could start an experimental branch for all this.

Br's,
Marius

On Dec 23, 2:42 am, David Pollak 
wrote:
> On Tue, Dec 22, 2009 at 3:47 PM, Peter Robinett 
> wrote:
>
> > Since Lift is so great at handling Comet updates, we might want to
> > take a look at supporting WebSockets which will (hopefully) be part of
> > HTML5. Here are a few links I just found:
> > -http://dev.w3.org/html5/websockets/
> > -
> >http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-li...
> > -http://www.igvita.com/2009/12/22/ruby-websockets-tcp-for-the-browser/
>
> > Anyway, food for thought.
>
> My (long time) plan is to auto-detect if the browser and the server supports
> web sockets and do the Comet stuff via websockets if both sides allow it.
>
>
>
>
>
> > Peter
>
> > --
>
> > 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 simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Problem with LiftFilter in 2.8.0

[Randinn]

This is not the first time this has cropped up, you may have to sticky
warning not to use 2.8 with Lift for the moment.

On Dec 23, 2:55 pm, David Pollak 
wrote:
> Lift *DOES NOT* work on Scala 2.8 Beta1 RC4 & 5.  Do not even try it.  We
> are currently working with EPFL to resolve these issues.
>
> Lift 1.1-M8 and Lift 1.1-SNAPSHOT only work with Scala 2.7.7.  That is the
> *only* version of Scala that Lift 1.1-M8 and SNAPSHOT work with.  If you
> have any other version of Scala specified in your pom.xml file, it will not
> work.
>
> Do not try to mix different versions of Lift in the same web app.  The class
> loader will not know which versions of the Lift library go with different
> Servlets.
>
> Once you get your pom.xml file set up with Scala 2.7.7, then you must do a
> "mvn -U clean install" before doing an mvn jetty:run
>
>
>
> On Tue, Dec 22, 2009 at 7:39 PM, Alan M  wrote:
> > Update:
>
> > I updated the other servlet to scala 2.8 and lift 1.1 snapshot (much
> > easier than I thought, I must be getting used to it) and I checked the
> > libs for both webapps and the commons lib directory.. no conflicting
> > versions of scala or lift jars.. I'm on Tomcat 6 btw..  Not sure where
> > to look next..
>
> > Alan
>
> > On Dec 22, 7:13 pm, Ross Mellgren  wrote:
> > > Where do you have the scala library jars? If you haven't taken pains to
> > ensure that you have two entirely separate scala JARs (2.7.3 and 2.8) in two
> > separate classloaders I could believe that you'll get all kinds of problems
> > like this. You might be better served using two separate tomcat instances
> > and some kind of reverse proxy like nginx to ensure they remain entirely
> > separated.
>
> > > -Ross
>
> > > On Dec 22, 2009, at 10:07 PM, Alan M wrote:
>
> > > > I get this message when it tries to initialize the LiftFilter..
>
> > > > Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
> > > > filterStart
> > > > SEVERE: Exception starting filter LiftFilter
> > > > java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
> > > > Ljava/lang/Object;
> > > >        at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
> > > > 53)
> > > >        at net.liftweb.util.Helpers$.first(Helpers.scala:32)
> > > >        at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
> > > >        at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
> > > >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > > >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > > >        at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
> > > >        at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
> > > > (Log.scala:141)
> > > >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > > >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > > >        at net.liftweb.util.Log$.rootLogger(Log.scala:27)
> > > >        at net.liftweb.util.Log$.error(Log.scala:43)
> > > >        at net.liftweb.http.provider.HTTPProvider$class.bootLift
> > > > (HTTPProvider.scala:80)
> > > >        at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
> > > >        at net.liftweb.http.provider.servlet.ServletFilterProvider
> > > > $class.init(ServletFilterProvider.scala:23)
> > > >        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)
>
> > > > Are multiple versions of Scala or Lift getting messed up here?  I have
> > > > two different Lift based servlets on this tomcat, one with Scala 2.7.3
> > > > and an older lift version and one with Scala 2.8 and the newest lift
> > > > version..
>
> > > > I guess I'm just trying to avoid updating that other servlet because
> > > > it's really not in my schedule right now..  Then again that might not
> > > > be the problem at all..
>
> > > > Alan
>
> > > > --
>
> > > > 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.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For mo

Re: [Lift] Goals for type and method renaming for Lift 2.0 - was: Open discussion on Lift Name Calling practices

[Naftoli Gugenheim]

Kris, can you look over and edit down your guidelines in the wiki? Thanks.

On Fri, Dec 18, 2009 at 3:18 AM, Heiko Seeberger <
heiko.seeber...@googlemail.com> wrote:

> Thank you for writing this up, Naftoli.
> I edited the abbreviation section ...
>
> Heiko
>
> 2009/12/18 Naftoli Gugenheim 
>
> (Not sure why on Chrome the wiki article page is all centered. Reported it
>> to Chrome.)
>>
>> Can everyone look over the article? Especially everyone "quoted" in it --
>> Kris, Jim, DPP, Heiko, and anyone who I may have missed -- can you make sure
>> everything represents your opinion correctly?
>> Then if there is any disagreement after everyone's opinion is clarified we
>> need to make some decisions together.
>> This should not take much time, but it's very valuable! Thanks.
>>
>>
>> 2009/12/15 Naftoli Gugenheim 
>>
>> I compiled much of this thread into
>>> http://wiki.github.com/dpp/liftweb/about-naming-conventions in raw form.
>>> As we continue to discuss the naming goals and guidelines and vote or decide
>>> on controversial goals, that wiki page should become more consolidated and
>>> less of a copy-paste of a discussion. :)
>>>
>>>
>>> On Mon, Dec 14, 2009 at 6:32 PM, Kris Nuttycombe <
>>> kris.nuttyco...@gmail.com> wrote:
>>>
 On Mon, Dec 14, 2009 at 12:31 PM, David Pollak
  wrote:
 > Folks,
 >
 > Lift allows developers to create web sites that are:
 >
 > Reliable (which includes secure)
 > Maintainable/concise
 > Highly interactive
 > Easy to build
 > High Performance
 > Easy to on-board (initial understanding of the APIs)
 >
 > Lift's APIs should reflect these rank-ordered goals.  Some of these
 goals
 > are in tension with each other.  For example, easy on-boarding (e.g.,
 longer
 > method names, more traditional imperative style) is in tension with
 concise.
 >
 > There's also a very diverse Lift community.
 >
 > I use Emacs for a lot of my Lift coding.  I know folks who use
 TextMate for
 > Lift coding.  Having long method names assumes the use of an IDE which
 has
 > name completion.  Lift's APIs must serve both communities.
 > People are coming to Lift from Java, Ruby, PHP, and other backgrounds.
 > Assuming Scala conventions rather than a "best choice" for naming does
 a
 > dis-service to the polygots.  Further, most of Scala's API conventions
 > except for the collections stuff is not in my opinion that well
 thought out
 > or consistent.
 > Many of Lift's APIs have evolved correctly based on actual usage
 patterns.
 > For example, the initially counter-intuitive use of apply to set
 fields and
 > vars works far better than any other mechanism, especially when
 chaining
 > calls.  I've tried many different mechanisms (e.g., update(), Pascal
 style
 > :=, set(), etc.) for setting fields and the one that everybody
 gravitated to
 > was apply().
 >
 > We also have to consider the existing code base.  I've personally got
 150K
 > lines of Lift-code under management.  If we start breaking APIs
 without a
 > compelling reason, it costs me money and it costs my clients less of
 my
 > time.  What's the impact to various different current users of Lift of
 > breaking APIs without a compelling reason (and "I like this name
 better than
 > that name" or "this name is more consistent" are not compelling
 reasons.)
 > So, my criteria for any name changes (and this is not open to any type
 of
 > negotiation and I've been 100% consistent about this since the
 discussion
 > began) is:
 >
 > If the name change can be accomplished with a deprecation of the old
 name
 > without breaking any existing APIs, then the name change can be the
 "better"
 > name.
 > If the name change is internal to Lift or is in a little-used feature
 (e.g.,
 > Kris's API changes in Loc) such that very few projects will likely be
 > impacted by a name change and those that are impacted are sufficiently
 savvy
 > that they will understand the change and be able to make it in a
 matter of
 > minutes.
 > Any class name or object name change that does not meet the above
 criteria
 > must be compelling.  For example, we changed from Scala Actors to Lift
 > Actors.  This was a substantial amount of breakage, but there were no
 > alternatives and the Scala Actor memory retention issues were
 materially
 > impacting many different sites and we had worked on various attempted
 > solutions over a 10 month period.  If we're going to break without
 > deprecation and the breakage is going to impact a substantial part of
 the
 > Lift community, there must be a compelling reason to make the
 breakage.
 >
 > On Sun, Dec 13, 2009 at 10:49 AM, Kris Nuttycombe
 >  wrote:
 >>
 >> To this po

Re: [Lift] Re: 280_port and yuicompressor problem

[David Pollak]

We are not officially supporting Scala 2.8 Beta1 RCxxx.  Until Scala 2.8
Beta1 is released, there will be no attempts to make this stuff work.

Please use Scala 2.7.7

If you have a production application and a compelling reason for using Scala
2.8, please contact me off-list to discuss support options (although I would
suggest running a production app on Scala 2.8 pre-beta.)

On Tue, Dec 22, 2009 at 7:00 PM, Alan M  wrote:

> OK cool.. thanks.. I'll look it up.  For now I just excluded it.
>
> Alan
>
> On Dec 21, 5:24 pm, Xuefeng Wu  wrote:
> > If you google "[yuicompressor:compress {execution: default}]" would find
> so
> > many information about this.
> > It's not caused by scala2.8 or lift.
> >
> >
> >
> > On Tue, Dec 22, 2009 at 9:10 AM, Alan M 
> wrote:
> > > I just recently started tinkering around with 2.8.. actually a recent
> > > upgrade of Netbeans kind of necessitated it.. (the only Scala plugin
> > > for Netbeans 6.8 requires Scala 2.8.xxx, ughh).
> >
> > > So most of my code is close anyway, except for anything that depends
> > > on specs.  But I had to get the 280_port of lift to compile locally
> > > for my web services.  When I try it fails very near the end with:
> > > ...
> > > [INFO] [yuicompressor:compress {execution: default}]
> > > [INFO]
> > >
> 
> > > [ERROR] FATAL ERROR
> > > [INFO]
> > >
> 
> > > [INFO] null
> > > [INFO]
> > >
> 
> > > [INFO] Trace
> > > java.lang.RuntimeException
> > >at
> > >
> com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber
> > > (JavaScriptCompressor.java:299)
> > >at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse
> > > (JavaScriptCompressor.java:335)
> > >at com.yahoo.platform.yui.compressor.JavaScriptCompressor.
> > > (JavaScriptCompressor.java:532)
> > >at
> net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile
> > > (YuiCompressorMojo.java:178)
> > > ...
> >
> > > I'm using maven 2.2.1 and Java 1.6.0.0 on Ubuntu.
> >
> > > Any ideas?
> >
> > > Alan
> >
> > > --
> >
> > > 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.
> >
> > --
> > 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, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Problem with LiftFilter in 2.8.0

[David Pollak]

Lift *DOES NOT* work on Scala 2.8 Beta1 RC4 & 5.  Do not even try it.  We
are currently working with EPFL to resolve these issues.

Lift 1.1-M8 and Lift 1.1-SNAPSHOT only work with Scala 2.7.7.  That is the
*only* version of Scala that Lift 1.1-M8 and SNAPSHOT work with.  If you
have any other version of Scala specified in your pom.xml file, it will not
work.

Do not try to mix different versions of Lift in the same web app.  The class
loader will not know which versions of the Lift library go with different
Servlets.

Once you get your pom.xml file set up with Scala 2.7.7, then you must do a
"mvn -U clean install" before doing an mvn jetty:run

On Tue, Dec 22, 2009 at 7:39 PM, Alan M  wrote:

> Update:
>
> I updated the other servlet to scala 2.8 and lift 1.1 snapshot (much
> easier than I thought, I must be getting used to it) and I checked the
> libs for both webapps and the commons lib directory.. no conflicting
> versions of scala or lift jars.. I'm on Tomcat 6 btw..  Not sure where
> to look next..
>
> Alan
>
> On Dec 22, 7:13 pm, Ross Mellgren  wrote:
> > Where do you have the scala library jars? If you haven't taken pains to
> ensure that you have two entirely separate scala JARs (2.7.3 and 2.8) in two
> separate classloaders I could believe that you'll get all kinds of problems
> like this. You might be better served using two separate tomcat instances
> and some kind of reverse proxy like nginx to ensure they remain entirely
> separated.
> >
> > -Ross
> >
> > On Dec 22, 2009, at 10:07 PM, Alan M wrote:
> >
> > > I get this message when it tries to initialize the LiftFilter..
> >
> > > Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
> > > filterStart
> > > SEVERE: Exception starting filter LiftFilter
> > > java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
> > > Ljava/lang/Object;
> > >at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
> > > 53)
> > >at net.liftweb.util.Helpers$.first(Helpers.scala:32)
> > >at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
> > >at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
> > >at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > >at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > >at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
> > >at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
> > > (Log.scala:141)
> > >at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > >at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > >at net.liftweb.util.Log$.rootLogger(Log.scala:27)
> > >at net.liftweb.util.Log$.error(Log.scala:43)
> > >at net.liftweb.http.provider.HTTPProvider$class.bootLift
> > > (HTTPProvider.scala:80)
> > >at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
> > >at net.liftweb.http.provider.servlet.ServletFilterProvider
> > > $class.init(ServletFilterProvider.scala:23)
> > >at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)
> >
> > > Are multiple versions of Scala or Lift getting messed up here?  I have
> > > two different Lift based servlets on this tomcat, one with Scala 2.7.3
> > > and an older lift version and one with Scala 2.8 and the newest lift
> > > version..
> >
> > > I guess I'm just trying to avoid updating that other servlet because
> > > it's really not in my schedule right now..  Then again that might not
> > > be the problem at all..
> >
> > > Alan
> >
> > > --
> >
> > > 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.
>
>
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] re: How do I get the stacktrace when EntityManager fails to be instantiated

[James Black]

I am having a problem with one entity trying to use @OneToMany, and I
would like to see what the actual error is, but that seems to be
getting absorbed.

For more on my actual problem you can look at this:

http://stackoverflow.com/questions/1947627/entitymanager-fails-to-instantiate-using-jpa-hibernate-when-i-add-a-onetomany-ann

This is my values within persistence.xml:

 
 
 
 
 
 
 

All I get when I have deleted the database, and then do 'mvn clean
compile install' at the end of my unit test is:
13853 [main] INFO org.hibernate.cfg.SettingsFactory - Deleted entity
synthetic identifier rollback: disabled
13853 [main] INFO org.hibernate.cfg.SettingsFactory - Default entity-
mode: pojo
13853 [main] INFO org.hibernate.cfg.SettingsFactory - Named query
checking : enabled
13858 [main] INFO org.hibernate.impl.SessionFactoryImpl - building
session factory
[PersistenceUnit: jpaweb] Unable to build EntityManagerFactory


I would like to see the exception that leads to it not being able to
build the EntityManagerFactory.

--

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: Problem with LiftFilter in 2.8.0

[Alan M]

A little more info.. I just tried to run one of the servlets stand
alone using jetty:run and it had the same problem..

Alan

On Dec 22, 7:39 pm, Alan M  wrote:
> Update:
>
> I updated the other servlet to scala 2.8 and lift 1.1 snapshot (much
> easier than I thought, I must be getting used to it) and I checked the
> libs for both webapps and the commons lib directory.. no conflicting
> versions of scala or lift jars.. I'm on Tomcat 6 btw..  Not sure where
> to look next..
>
> Alan
>
> On Dec 22, 7:13 pm, Ross Mellgren  wrote:
>
> > Where do you have the scala library jars? If you haven't taken pains to 
> > ensure that you have two entirely separate scala JARs (2.7.3 and 2.8) in 
> > two separate classloaders I could believe that you'll get all kinds of 
> > problems like this. You might be better served using two separate tomcat 
> > instances and some kind of reverse proxy like nginx to ensure they remain 
> > entirely separated.
>
> > -Ross
>
> > On Dec 22, 2009, at 10:07 PM, Alan M wrote:
>
> > > I get this message when it tries to initialize the LiftFilter..
>
> > > Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
> > > filterStart
> > > SEVERE: Exception starting filter LiftFilter
> > > java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
> > > Ljava/lang/Object;
> > >        at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
> > > 53)
> > >        at net.liftweb.util.Helpers$.first(Helpers.scala:32)
> > >        at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
> > >        at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
> > >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> > >        at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
> > >        at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
> > > (Log.scala:141)
> > >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> > >        at net.liftweb.util.Log$.rootLogger(Log.scala:27)
> > >        at net.liftweb.util.Log$.error(Log.scala:43)
> > >        at net.liftweb.http.provider.HTTPProvider$class.bootLift
> > > (HTTPProvider.scala:80)
> > >        at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
> > >        at net.liftweb.http.provider.servlet.ServletFilterProvider
> > > $class.init(ServletFilterProvider.scala:23)
> > >        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)
>
> > > Are multiple versions of Scala or Lift getting messed up here?  I have
> > > two different Lift based servlets on this tomcat, one with Scala 2.7.3
> > > and an older lift version and one with Scala 2.8 and the newest lift
> > > version..
>
> > > I guess I'm just trying to avoid updating that other servlet because
> > > it's really not in my schedule right now..  Then again that might not
> > > be the problem at all..
>
> > > Alan
>
> > > --
>
> > > 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.

[Lift] Re: Problem with LiftFilter in 2.8.0

[Alan M]

Update:

I updated the other servlet to scala 2.8 and lift 1.1 snapshot (much
easier than I thought, I must be getting used to it) and I checked the
libs for both webapps and the commons lib directory.. no conflicting
versions of scala or lift jars.. I'm on Tomcat 6 btw..  Not sure where
to look next..

Alan

On Dec 22, 7:13 pm, Ross Mellgren  wrote:
> Where do you have the scala library jars? If you haven't taken pains to 
> ensure that you have two entirely separate scala JARs (2.7.3 and 2.8) in two 
> separate classloaders I could believe that you'll get all kinds of problems 
> like this. You might be better served using two separate tomcat instances and 
> some kind of reverse proxy like nginx to ensure they remain entirely 
> separated.
>
> -Ross
>
> On Dec 22, 2009, at 10:07 PM, Alan M wrote:
>
> > I get this message when it tries to initialize the LiftFilter..
>
> > Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
> > filterStart
> > SEVERE: Exception starting filter LiftFilter
> > java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
> > Ljava/lang/Object;
> >        at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
> > 53)
> >        at net.liftweb.util.Helpers$.first(Helpers.scala:32)
> >        at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
> >        at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
> >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> >        at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
> >        at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
> >        at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
> > (Log.scala:141)
> >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> >        at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
> >        at net.liftweb.util.Log$.rootLogger(Log.scala:27)
> >        at net.liftweb.util.Log$.error(Log.scala:43)
> >        at net.liftweb.http.provider.HTTPProvider$class.bootLift
> > (HTTPProvider.scala:80)
> >        at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
> >        at net.liftweb.http.provider.servlet.ServletFilterProvider
> > $class.init(ServletFilterProvider.scala:23)
> >        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)
>
> > Are multiple versions of Scala or Lift getting messed up here?  I have
> > two different Lift based servlets on this tomcat, one with Scala 2.7.3
> > and an older lift version and one with Scala 2.8 and the newest lift
> > version..
>
> > I guess I'm just trying to avoid updating that other servlet because
> > it's really not in my schedule right now..  Then again that might not
> > be the problem at all..
>
> > Alan
>
> > --
>
> > 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] Problem with LiftFilter in 2.8.0

[Ross Mellgren]

Where do you have the scala library jars? If you haven't taken pains to ensure 
that you have two entirely separate scala JARs (2.7.3 and 2.8) in two separate 
classloaders I could believe that you'll get all kinds of problems like this. 
You might be better served using two separate tomcat instances and some kind of 
reverse proxy like nginx to ensure they remain entirely separated.

-Ross

On Dec 22, 2009, at 10:07 PM, Alan M wrote:

> I get this message when it tries to initialize the LiftFilter..
> 
> Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
> filterStart
> SEVERE: Exception starting filter LiftFilter
> java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
> Ljava/lang/Object;
>at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
> 53)
>at net.liftweb.util.Helpers$.first(Helpers.scala:32)
>at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
>at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
>at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
>at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
>at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
>at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
> (Log.scala:141)
>at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
>at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
>at net.liftweb.util.Log$.rootLogger(Log.scala:27)
>at net.liftweb.util.Log$.error(Log.scala:43)
>at net.liftweb.http.provider.HTTPProvider$class.bootLift
> (HTTPProvider.scala:80)
>at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
>at net.liftweb.http.provider.servlet.ServletFilterProvider
> $class.init(ServletFilterProvider.scala:23)
>at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)
> 
> Are multiple versions of Scala or Lift getting messed up here?  I have
> two different Lift based servlets on this tomcat, one with Scala 2.7.3
> and an older lift version and one with Scala 2.8 and the newest lift
> version..
> 
> I guess I'm just trying to avoid updating that other servlet because
> it's really not in my schedule right now..  Then again that might not
> be the problem at all..
> 
> Alan
> 
> --
> 
> 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] Problem with LiftFilter in 2.8.0

[Alan M]

I get this message when it tries to initialize the LiftFilter..

Dec 22, 2009 6:53:40 PM org.apache.catalina.core.StandardContext
filterStart
SEVERE: Exception starting filter LiftFilter
java.lang.NoSuchMethodError: scala.collection.SeqLike.projection()
Ljava/lang/Object;
at net.liftweb.util.ListHelpers$class.first(ListHelpers.scala:
53)
at net.liftweb.util.Helpers$.first(Helpers.scala:32)
at net.liftweb.util.LogBoot$.findTheFile$1(Log.scala:117)
at net.liftweb.util.LogBoot$._log4JSetup(Log.scala:119)
at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
at net.liftweb.util.LogBoot$$anonfun$1.apply(Log.scala:97)
at net.liftweb.util.LogBoot$.checkConfig(Log.scala:95)
at net.liftweb.util.LogBoot$.net$liftweb$util$LogBoot$$_logger
(Log.scala:141)
at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
at net.liftweb.util.LogBoot$$anonfun$2.apply(Log.scala:143)
at net.liftweb.util.Log$.rootLogger(Log.scala:27)
at net.liftweb.util.Log$.error(Log.scala:43)
at net.liftweb.http.provider.HTTPProvider$class.bootLift
(HTTPProvider.scala:80)
at net.liftweb.http.LiftFilter.bootLift(LiftServlet.scala:524)
at net.liftweb.http.provider.servlet.ServletFilterProvider
$class.init(ServletFilterProvider.scala:23)
at net.liftweb.http.LiftFilter.init(LiftServlet.scala:524)

Are multiple versions of Scala or Lift getting messed up here?  I have
two different Lift based servlets on this tomcat, one with Scala 2.7.3
and an older lift version and one with Scala 2.8 and the newest lift
version..

I guess I'm just trying to avoid updating that other servlet because
it's really not in my schedule right now..  Then again that might not
be the problem at all..

Alan

--

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: 280_port and yuicompressor problem

[Alan M]

OK cool.. thanks.. I'll look it up.  For now I just excluded it.

Alan

On Dec 21, 5:24 pm, Xuefeng Wu  wrote:
> If you google "[yuicompressor:compress {execution: default}]" would find so
> many information about this.
> It's not caused by scala2.8 or lift.
>
>
>
> On Tue, Dec 22, 2009 at 9:10 AM, Alan M  wrote:
> > I just recently started tinkering around with 2.8.. actually a recent
> > upgrade of Netbeans kind of necessitated it.. (the only Scala plugin
> > for Netbeans 6.8 requires Scala 2.8.xxx, ughh).
>
> > So most of my code is close anyway, except for anything that depends
> > on specs.  But I had to get the 280_port of lift to compile locally
> > for my web services.  When I try it fails very near the end with:
> > ...
> > [INFO] [yuicompressor:compress {execution: default}]
> > [INFO]
> > 
> > [ERROR] FATAL ERROR
> > [INFO]
> > 
> > [INFO] null
> > [INFO]
> > 
> > [INFO] Trace
> > java.lang.RuntimeException
> >        at
> > com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber
> > (JavaScriptCompressor.java:299)
> >        at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse
> > (JavaScriptCompressor.java:335)
> >        at com.yahoo.platform.yui.compressor.JavaScriptCompressor.
> > (JavaScriptCompressor.java:532)
> >        at net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile
> > (YuiCompressorMojo.java:178)
> > ...
>
> > I'm using maven 2.2.1 and Java 1.6.0.0 on Ubuntu.
>
> > Any ideas?
>
> > Alan
>
> > --
>
> > 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.
>
> --
> 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: The future of lift-core

[Peter Robinett]

Indrajit, your post made me realize that I've been using lift-core
without realizing it. Thanks.

Unfortunately switching to something simpler is giving me some
trouble. I believe that I should be able to add lift-base, but while
its sub-modules get downloaded (lift-common, lift-util, etc), Maven
says that the lift-base module is missing and needs to be installed.
This is the entry I'm using:

  net.liftweb
  lift-base
  1.1-SNAPSHOT


As the resident Maven expert, do you have any idea what's wrong? My
entire pom.xml is here: http://gist.github.com/262244

Thanks,
Peter

On Dec 22, 8:32 am, Indrajit Raychaudhuri  wrote:
> On 22/12/09 12:23 AM, David Pollak wrote:
>
>
>
>
>
>
>
> > On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri
> > mailto:indraj...@gmail.com>> wrote:
>
> >     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,
>
> > Lift 2.0 is not "coming up" it's merely a rename of Lift 1.1 based on
> > the naming rules that Heiko proposed and the Lift community adopted.
> > The fact that the next release of Lift is going to be called 2.0 rather
> > than 1.1 does not change the scope of the release.
>
> Indeed, poor wordings, Lift 2.0 *restructure* coming up is what I meant.
> But yes, it ends up sounding different, sorry.
>
>
>
> > With that being said, deprecating lift-core is fine by me as long as
> > there is an easy to understand deprecation message with clear
> > instructions as to how to replace lift-core with whatever is necessary.
>
> For deprecating dependencies, it's just matter of persuasion
> (Announcement, wiki etc.) for at least two releases, or more (could be
> milestone releases). And eventually, dropping it from the build beyond
> an agreeable release time frame.
>
> I couldn't figure out a clean way of deprecating 'meta' packages since
> it doesn't have any active code (thus doesn't expose any place to code
> in some deprecation warning message).
>
> As such, the package is harmless and there is zero cost of maintenance.
> Just that, it's no more a good practice (longer build time, larger war
> size etc.).
>
>
>
>
>
> >     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 liftweb@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 simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics
>
> > --
>
> > You received this message because you are subscribed to the Google
> > Groups "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.

--

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: WebSockets are Coming

[Peter Robinett]

That would be very elegant.

On Dec 22, 4:42 pm, David Pollak 
wrote:
> On Tue, Dec 22, 2009 at 3:47 PM, Peter Robinett 
> wrote:
>
> > Since Lift is so great at handling Comet updates, we might want to
> > take a look at supporting WebSockets which will (hopefully) be part of
> > HTML5. Here are a few links I just found:
> > -http://dev.w3.org/html5/websockets/
> > -
> >http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-li...
> > -http://www.igvita.com/2009/12/22/ruby-websockets-tcp-for-the-browser/
>
> > Anyway, food for thought.
>
> My (long time) plan is to auto-detect if the browser and the server supports
> web sockets and do the Comet stuff via websockets if both sides allow it.
>
>
>
>
>
>
>
> > Peter
>
> > --
>
> > 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 simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Lift and chunked transfer-encoding

[Alex Black]

That could definitely work.

I'd still (even for curiosity's sake) be interested in lower level
access to the response, e.g. response.write that goes right out to the
client.

On Dec 22, 7:36 pm, David Pollak 
wrote:
> On Tue, Dec 22, 2009 at 4:28 PM, Alex Black  wrote:
> > Hi David,
>
> > Its a huge-ass google sitemap, so I'm forming XML for it, and its
> > really large, and I thought I'd send chunks of it out at a time rather
> > than composing all of it in RAM before sending it out.
>
> How about composing it as a big file on disk and use the StreamingResponse
> class?
>
>
>
>
>
>
>
> > - Alex
>
> > On Dec 22, 5:56 pm, David Pollak 
> > wrote:
> > > On Tue, Dec 22, 2009 at 2:38 PM, Alex Black  wrote:
> > > > I've got a large response I'd like to send out, and I'd like to chunk
> > > > it up.
>
> > > >http://en.wikipedia.org/wiki/Chunked_transfer_encoding
>
> > > > Does Lift provide any built in support for this?
>
> > > No.
>
> > > > I've explored using StreamingResponse, but it expects a dataLength,
> > > > which I don't have.  I had hoped to provide it a stream which would
> > > > provide each chunk.
>
> > > > Is there a lower level mechanism to write data out?
>
> > > Not really.  Can you describe your use case a little more?  For very
> > large
> > > responses (e.g., a large PDF), in what case would you not know the
> > length?
>
> > > > - 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 > > >  >
> >  > s.com>>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/liftweb?hl=en.
>
> > > --
> > > Lift, the simply functional web frameworkhttp://liftweb.net
> > > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > > Follow me:http://twitter.com/dpp
> > > Surf the harmonics
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Lift" group.
> > To post to this group, send email to lift...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+unsubscr...@googlegroups.com > >
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/liftweb?hl=en.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] WebSockets are Coming

[David Pollak]

On Tue, Dec 22, 2009 at 3:47 PM, Peter Robinett wrote:

> Since Lift is so great at handling Comet updates, we might want to
> take a look at supporting WebSockets which will (hopefully) be part of
> HTML5. Here are a few links I just found:
> - http://dev.w3.org/html5/websockets/
> -
> http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html
> - http://www.igvita.com/2009/12/22/ruby-websockets-tcp-for-the-browser/
>
> Anyway, food for thought.
>

My (long time) plan is to auto-detect if the browser and the server supports
web sockets and do the Comet stuff via websockets if both sides allow it.


>
> Peter
>
> --
>
> 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 simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: Lift and chunked transfer-encoding

[David Pollak]

On Tue, Dec 22, 2009 at 4:28 PM, Alex Black  wrote:

> Hi David,
>
> Its a huge-ass google sitemap, so I'm forming XML for it, and its
> really large, and I thought I'd send chunks of it out at a time rather
> than composing all of it in RAM before sending it out.
>

How about composing it as a big file on disk and use the StreamingResponse
class?


>
> - Alex
>
> On Dec 22, 5:56 pm, David Pollak 
> wrote:
> > On Tue, Dec 22, 2009 at 2:38 PM, Alex Black  wrote:
> > > I've got a large response I'd like to send out, and I'd like to chunk
> > > it up.
> >
> > >http://en.wikipedia.org/wiki/Chunked_transfer_encoding
> >
> > > Does Lift provide any built in support for this?
> >
> > No.
> >
> >
> >
> > > I've explored using StreamingResponse, but it expects a dataLength,
> > > which I don't have.  I had hoped to provide it a stream which would
> > > provide each chunk.
> >
> > > Is there a lower level mechanism to write data out?
> >
> > Not really.  Can you describe your use case a little more?  For very
> large
> > responses (e.g., a large PDF), in what case would you not know the
> length?
> >
> >
> >
> >
> >
> >
> >
> > > - 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.
> >
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
>


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Lift and chunked transfer-encoding

[Alex Black]

Hi David,

Its a huge-ass google sitemap, so I'm forming XML for it, and its
really large, and I thought I'd send chunks of it out at a time rather
than composing all of it in RAM before sending it out.

- Alex

On Dec 22, 5:56 pm, David Pollak 
wrote:
> On Tue, Dec 22, 2009 at 2:38 PM, Alex Black  wrote:
> > I've got a large response I'd like to send out, and I'd like to chunk
> > it up.
>
> >http://en.wikipedia.org/wiki/Chunked_transfer_encoding
>
> > Does Lift provide any built in support for this?
>
> No.
>
>
>
> > I've explored using StreamingResponse, but it expects a dataLength,
> > which I don't have.  I had hoped to provide it a stream which would
> > provide each chunk.
>
> > Is there a lower level mechanism to write data out?
>
> Not really.  Can you describe your use case a little more?  For very large
> responses (e.g., a large PDF), in what case would you not know the length?
>
>
>
>
>
>
>
> > - 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.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Date/Time/DateTime formatters and parsers

[Naftoli Gugenheim]

What ever happened to having separate formatters and parsers for MappedDate vs. 
MappedTime vs. MappedDateTime, or specifying them on a field by field basis?
Thanks.

--

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] WebSockets are Coming

[Timothy Perrett]

We have been planning web socket support for like the past 18  
months... It was always a long tern goal of lift to implement  
websockets as soon as there were stable implementations. Only now are  
we seeing that happen, so, thus, I would imagine dpp or Marius would  
take the lead on this when they feel it's appropriate to do so.

Cheers, Tim

Sent from my iPhone

On 22 Dec 2009, at 23:47, Peter Robinett   
wrote:

> Since Lift is so great at handling Comet updates, we might want to
> take a look at supporting WebSockets which will (hopefully) be part of
> HTML5. Here are a few links I just found:
> - http://dev.w3.org/html5/websockets/
> - 
> http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html
> - http://www.igvita.com/2009/12/22/ruby-websockets-tcp-for-the- 
> browser/
>
> Anyway, food for thought.
>
> Peter
>
> --
>
> 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] WebSockets are Coming

[Peter Robinett]

Since Lift is so great at handling Comet updates, we might want to
take a look at supporting WebSockets which will (hopefully) be part of
HTML5. Here are a few links I just found:
- http://dev.w3.org/html5/websockets/
- 
http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html
- http://www.igvita.com/2009/12/22/ruby-websockets-tcp-for-the-browser/

Anyway, food for thought.

Peter

--

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 and chunked transfer-encoding

[David Pollak]

On Tue, Dec 22, 2009 at 2:38 PM, Alex Black  wrote:

> I've got a large response I'd like to send out, and I'd like to chunk
> it up.
>
> http://en.wikipedia.org/wiki/Chunked_transfer_encoding
>
> Does Lift provide any built in support for this?
>

No.


>
> I've explored using StreamingResponse, but it expects a dataLength,
> which I don't have.  I had hoped to provide it a stream which would
> provide each chunk.
>
> Is there a lower level mechanism to write data out?
>

Not really.  Can you describe your use case a little more?  For very large
responses (e.g., a large PDF), in what case would you not know the length?


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


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Lift and chunked transfer-encoding

[Alex Black]

I've got a large response I'd like to send out, and I'd like to chunk
it up.

http://en.wikipedia.org/wiki/Chunked_transfer_encoding

Does Lift provide any built in support for this?

I've explored using StreamingResponse, but it expects a dataLength,
which I don't have.  I had hoped to provide it a stream which would
provide each chunk.

Is there a lower level mechanism to write data out?

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

[Lift] Re: Write table on the fly...

[Marius]

Perhaps something like:

 def tablaAmortizacion
 (xhtml:NodeSeq,monto:Double,amort:Double,start:java.util.Calendar):
NodeSeq =  {
 var formatter = new java.text.SimpleDateFormat("dd/MM/")
   var end = new java.util.GregorianCalendar()
 end.setTime(start.getTime)
 end.add(java.util.Calendar.MONTH,1)
 var difference = Math.abs(start.getTimeInMillis -
 end.getTimeInMillis)
 var days = difference / (1000 * 60 * 60 * 24)

 var resp: NodeSeq = {"Monto sal: " + monto + "
Amortizacion: " + amort +
 "   Start: " + formatter.format(start.getTime)  + "   End: " +
 formatter.format(end.getTime) + "   Days: " + days}

 if (monto > amort) {
 resp = resp ++ tablaAmortizacion(xhtml,monto-
amort,amort,end)
 }
 resp
 }


and in your Lift snippet just call your function and return the
resulting NodeSeq from your snippet

class MySnippet {

def snip(xhtml: NodeSeq) : NodeSeq = {
  tablaAmortizacion(...)
}

}

potentially use it in conjunction with bind etc.

Br's,
Marius

On Dec 22, 8:58 pm, Fernando  wrote:
> Hi,
>
> I have the following function, and I would like to write to the page
> instead of the println. How can I do that? I need a table with that
> information in my page, But I did't find any information about that, I
> saw how to write collections to the page, but I would rather prefer
> write to the page on the fly.
>
> Thanks in advance and I hope for your response.
>
>     def tablaAmortizacion
> (xhtml:NodeSeq,monto:Double,amort:Double,start:java.util.Calendar) {
>         var formatter = new java.text.SimpleDateFormat("dd/MM/")
>         var end = new java.util.GregorianCalendar()
>         end.setTime(start.getTime)
>         end.add(java.util.Calendar.MONTH,1)
>         var difference = Math.abs(start.getTimeInMillis -
> end.getTimeInMillis)
>         var days = difference / (1000 * 60 * 60 * 24)
>
>         println("Monto sal: " + monto + "   Amortizacion: " + amort +
> "   Start: " + formatter.format(start.getTime)  + "   End: " +
> formatter.format(end.getTime) + "   Days: " + days)
>
>         if (monto > amort) {
>             tablaAmortizacion(xhtml,monto-amort,amort,end)
>         }
>
>     }
>
> Fernando Avalos.

--

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] Write table on the fly...

[Fernando]

Hi,

I have the following function, and I would like to write to the page
instead of the println. How can I do that? I need a table with that
information in my page, But I did't find any information about that, I
saw how to write collections to the page, but I would rather prefer
write to the page on the fly.

Thanks in advance and I hope for your response.

def tablaAmortizacion
(xhtml:NodeSeq,monto:Double,amort:Double,start:java.util.Calendar) {
var formatter = new java.text.SimpleDateFormat("dd/MM/")
var end = new java.util.GregorianCalendar()
end.setTime(start.getTime)
end.add(java.util.Calendar.MONTH,1)
var difference = Math.abs(start.getTimeInMillis -
end.getTimeInMillis)
var days = difference / (1000 * 60 * 60 * 24)

println("Monto sal: " + monto + "   Amortizacion: " + amort +
"   Start: " + formatter.format(start.getTime)  + "   End: " +
formatter.format(end.getTime) + "   Days: " + days)

if (monto > amort) {
tablaAmortizacion(xhtml,monto-amort,amort,end)
}

}

Fernando Avalos.

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

On Tue, Dec 22, 2009 at 7:12 PM, Paul Phillips  wrote:
> On Tue, Dec 22, 2009 at 05:45:52PM +0100, martin odersky wrote:
>> But I need to know how to build lift with a 2.8.0 compiler. Or
>> alternatively, if a kind soul can send me a lift 2.8.0 tarball with
>> all the classfiles in there I can take it from there.
>
> FYI until you have git you can always download a tarball snapshot of the
> current head at github.  There's a "download" link here:
>
>  http://github.com/dpp/liftweb
>
> Except you need the 280_port branch, so here:
>
>  http://github.com/dpp/liftweb/tree/280_port
>
> And that download link goes here:
>
> http://github.com/dpp/liftweb/tarball/12d1bf0697c9c792c8c91416989a0ef7e287b156
>
> Assuming that gets the files it should, typing "mvn install" will try to
> build with 2.80 Beta1 RC3.  To use RC5 edit pom.xml with this diff:
>
> -    2.8.0.Beta1-RC3
> +    2.8.0.Beta1-RC5
>
> Instructions from earlier in this thread should get you to the point
> where you can build with the local compiler.
>
yes I got that working. The problem was that the download at 280_port
was not 280_port but (I guess) 280_dev. That got me stuck for a while,
but we sorted it out eventually.

Cheers

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Paul Phillips]

On Tue, Dec 22, 2009 at 05:45:52PM +0100, martin odersky wrote:
> But I need to know how to build lift with a 2.8.0 compiler. Or 
> alternatively, if a kind soul can send me a lift 2.8.0 tarball with 
> all the classfiles in there I can take it from there.

FYI until you have git you can always download a tarball snapshot of the 
current head at github.  There's a "download" link here:

  http://github.com/dpp/liftweb

Except you need the 280_port branch, so here:

  http://github.com/dpp/liftweb/tree/280_port

And that download link goes here:

http://github.com/dpp/liftweb/tarball/12d1bf0697c9c792c8c91416989a0ef7e287b156

Assuming that gets the files it should, typing "mvn install" will try to 
build with 2.80 Beta1 RC3.  To use RC5 edit pom.xml with this diff:

-2.8.0.Beta1-RC3
+2.8.0.Beta1-RC5

Instructions from earlier in this thread should get you to the point 
where you can build with the local compiler.

-- 
Paul Phillips  | Adultery is the application of democracy to love. 
Vivid  | -- H. L. Mencken
Empiricist | 
pull his pi pal!   |--* http://www.improving.org/paulp/ *--

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Indrajit Raychaudhuri]

Finally! Onward ...

- Indrajit

On 22/12/09 11:29 PM, martin odersky wrote:
> On Tue, Dec 22, 2009 at 6:48 PM, martin odersky  
> wrote:
>> I found someone who could download the repository with git. So trying
>> again now.
>
> ... and it builds with RC3. Great! So now I have something to work with ...
>
> Cheers
>
>   -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Indrajit Raychaudhuri]

On 22/12/09 11:06 PM, martin odersky wrote:
> On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
>   wrote:
>>
>> On 22/12/09 10:44 PM, martin odersky wrote:
>>>
>>> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
>>> wrote:

 Martin,

 I think the jetty version is incorrect in the pom.xml in test:sample.

 It should be:

 org.mortbay.jetty
 jetty
 [6.1.6,7.0)

>>> ... and, which test:sample are you referring to?
>>>
>>> Thanks
>>>
>>>   -- Martin
>>
>> The test:sample:war:0.1 artifact for which it fails. By your question, I
>> realize that you are encountering this during archetype generation. It's
>> completely unnecessary.
>>
>> edit the top level pom.xml and remove all the modules other than lift-base,
>> lift-persistence and lift-modules for now. They are really all that you
>> need.
>>
>> The modules section in your top level pom.xml should have just this.
>>
>>   
>> lift-base
>> lift-persistence
>> lift-modules
>> 
>> 
>>
>> 
>> 
>>   
>>
>> - Indrajit
>>
>>
> OK, that will help, I hope.
>
> But I still have no luck. When I download from
>
>http://github.com/dpp/liftweb/tree/280_port
>
> I get something that's different than the layout on the webpage.
> Subdirectories in dpp-liftweb-12d1bf0/
> are flatter than what I see on the webpage. When I compile with 2.8 it
> dies because it wants jcl.Conversions which sure does not exist
> anymore. So it seems to me that versions are mixed up? I really need a
> tarball or zip with the right lift to test against!

I just downloaded the zip from github page. Not sure how github prepares 
the archive. But I can confirm that dpp-liftweb-12d1bf0/ is incorrect.

>
>   -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

On Tue, Dec 22, 2009 at 6:48 PM, martin odersky  wrote:
> I found someone who could download the repository with git. So trying
> again now.

... and it builds with RC3. Great! So now I have something to work with ...

Cheers

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

I found someone who could download the repository with git. So trying
again now.

 -- Martin

On Tue, Dec 22, 2009 at 6:36 PM, martin odersky  wrote:
> On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
>  wrote:
>>
>> On 22/12/09 10:44 PM, martin odersky wrote:
>>>
>>> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
>>>   wrote:

 Martin,

 I think the jetty version is incorrect in the pom.xml in test:sample.

 It should be:

        org.mortbay.jetty
        jetty
        [6.1.6,7.0)

>>> ... and, which test:sample are you referring to?
>>>
>>> Thanks
>>>
>>>  -- Martin
>>
>> The test:sample:war:0.1 artifact for which it fails. By your question, I
>> realize that you are encountering this during archetype generation. It's
>> completely unnecessary.
>>
>> edit the top level pom.xml and remove all the modules other than lift-base,
>> lift-persistence and lift-modules for now. They are really all that you
>> need.
>>
>> The modules section in your top level pom.xml should have just this.
>>
>>  
>>    lift-base
>>    lift-persistence
>>    lift-modules
>>    
>>    
>>
>>    
>>    
>>  
>>
>> - Indrajit
>>
>>
> OK, that will help, I hope.
>
> But I still have no luck. When I download from
>
>  http://github.com/dpp/liftweb/tree/280_port
>
> I get something that's different than the layout on the webpage.
> Subdirectories in dpp-liftweb-12d1bf0/
> are flatter than what I see on the webpage. When I compile with 2.8 it
> dies because it wants jcl.Conversions which sure does not exist
> anymore. So it seems to me that versions are mixed up? I really need a
> tarball or zip with the right lift to test against!
>
>  -- Martin
>

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
 wrote:
>
> On 22/12/09 10:44 PM, martin odersky wrote:
>>
>> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
>>   wrote:
>>>
>>> Martin,
>>>
>>> I think the jetty version is incorrect in the pom.xml in test:sample.
>>>
>>> It should be:
>>>
>>>        org.mortbay.jetty
>>>        jetty
>>>        [6.1.6,7.0)
>>>
>> ... and, which test:sample are you referring to?
>>
>> Thanks
>>
>>  -- Martin
>
> The test:sample:war:0.1 artifact for which it fails. By your question, I
> realize that you are encountering this during archetype generation. It's
> completely unnecessary.
>
> edit the top level pom.xml and remove all the modules other than lift-base,
> lift-persistence and lift-modules for now. They are really all that you
> need.
>
> The modules section in your top level pom.xml should have just this.
>
>  
>    lift-base
>    lift-persistence
>    lift-modules
>    
>    
>
>    
>    
>  
>
> - Indrajit
>
>
OK, that will help, I hope.

But I still have no luck. When I download from

  http://github.com/dpp/liftweb/tree/280_port

I get something that's different than the layout on the webpage.
Subdirectories in dpp-liftweb-12d1bf0/
are flatter than what I see on the webpage. When I compile with 2.8 it
dies because it wants jcl.Conversions which sure does not exist
anymore. So it seems to me that versions are mixed up? I really need a
tarball or zip with the right lift to test against!

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Indrajit Raychaudhuri]

On 22/12/09 10:44 PM, martin odersky wrote:
> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
>   wrote:
>> Martin,
>>
>> I think the jetty version is incorrect in the pom.xml in test:sample.
>>
>> It should be:
>>
>> org.mortbay.jetty
>> jetty
>> [6.1.6,7.0)
>>
> ... and, which test:sample are you referring to?
>
> Thanks
>
>   -- Martin

The test:sample:war:0.1 artifact for which it fails. By your question, I 
realize that you are encountering this during archetype generation. It's 
completely unnecessary.

edit the top level pom.xml and remove all the modules other than 
lift-base, lift-persistence and lift-modules for now. They are really 
all that you need.

The modules section in your top level pom.xml should have just this.

   
 lift-base
 lift-persistence
 lift-modules
 
 

 
 
   

- Indrajit

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Indrajit Raychaudhuri]

Must be effect of some scala.version property set somewhere.

do "mvn -Dscala.version=2.8.0.Beta1-RC5" to enforce a different version.

- Indrajit

On 22/12/09 10:43 PM, martin odersky wrote:
> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
>   wrote:
>> Martin,
>>
>> I think the jetty version is incorrect in the pom.xml in test:sample.
>>
>> It should be:
>>
>> org.mortbay.jetty
>> jetty
>> [6.1.6,7.0)
>>
>> See if that works.
>>
> But even then I only get a 2.7.7 build, which is not what I need?
>
>   -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Ross Mellgren]

http://www.dridus.com/liftweb-compiled-280.tar.gz

It is still uploading -- it totals 240,976,056 bytes and should be  
completely uploaded in 15 minutes.

-Ross

On Dec 22, 2009, at 11:45 AM, martin odersky wrote:

> I just verified that it did indeed use 2.7.7, because the generated
> classfiles still have version 4.1.
>
> My new strategy is to build with the last working RC3, and then
> recompile just the failing file with the current compiler and all lift
> classes on the classpath. That should work.
>
> But I need to know how to build lift with a 2.8.0 compiler. Or
> alternatively, if a kind soul can send me a lift 2.8.0 tarball with
> all the classfiles in there I can take it from there.
>
> Thanks
>
> -- Martin
>
> --
>
> 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
 wrote:
> Martin,
>
> I think the jetty version is incorrect in the pom.xml in test:sample.
>
> It should be:
>
>        org.mortbay.jetty
>        jetty
>        [6.1.6,7.0)
>
... and, which test:sample are you referring to?

Thanks

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
 wrote:
> Martin,
>
> I think the jetty version is incorrect in the pom.xml in test:sample.
>
> It should be:
>
>        org.mortbay.jetty
>        jetty
>        [6.1.6,7.0)
>
> See if that works.
>
But even then I only get a 2.7.7 build, which is not what I need?

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Indrajit Raychaudhuri]

Martin,

I think the jetty version is incorrect in the pom.xml in test:sample.

It should be:

 org.mortbay.jetty
 jetty
 [6.1.6,7.0)

See if that works.

Regards, Indrajit


On 22/12/09 10:14 PM, martin odersky wrote:
> Thanks for all the help. I tried to do
>
> mvn clean
> mvn install
>
> After upgrading to maven 2.2.1, I got somewhere. It compiled a bunch
> of packages including lift-mapper, so it seems it did not in fact take
> RC6 as its compiler?
>
> But then it stopped due to a build error here.
>
> Any idea what I need to do to solve this?
>
> Thanks
>
>   -- martin
>
>
>
> [INFO] [INFO] 
> 
> [INFO] [ERROR] BUILD ERROR
> [INFO] [INFO] 
> 
> [INFO] [INFO] Failed to resolve artifact.
> [INFO]
> [INFO] Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19,
> 6.1.20, 6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
> [INFO]   org.mortbay.jetty:jetty:jar:null
> [INFO]
> [INFO] from the specified remote repositories:
> [INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
> [INFO]   central (http://repo1.maven.org/maven2),
> [INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
> [INFO]
> [INFO] Path to dependency:
> [INFO]  1) test:sample:war:0.1
> [INFO]
> [INFO]
> [INFO]
> [INFO] [INFO] 
> 
> [INFO] [INFO] Trace
> [INFO] org.apache.maven.lifecycle.LifecycleExecutionException:
> Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20,
> 6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
> [INFO]   org.mortbay.jetty:jetty:jar:null
> [INFO]
> [INFO] from the specified remote repositories:
> [INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
> [INFO]   central (http://repo1.maven.org/maven2),
> [INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
> [INFO]
> [INFO] Path to dependency:
> [INFO]  1) test:sample:war:0.1
> [INFO]
> [INFO]
> [INFO]  at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711)
> [INFO]  at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> [INFO]  at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> [INFO]  at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> [INFO]  at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> [INFO]  at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> [INFO]  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> [INFO]  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> [INFO]  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> [INFO]  at 
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> [INFO]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [INFO]  at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [INFO]  at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> [INFO]  at java.lang.reflect.Method.invoke(Method.java:597)
> [INFO]  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> [INFO]  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> [INFO]  at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> [INFO]  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO] Caused by:
> org.apache.maven.artifact.versioning.OverConstrainedVersionException:
> Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20,
> 6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
> [INFO]   org.mortbay.jetty:jetty:jar:null
> [INFO]
> [INFO] from the specified remote repositories:
> [INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
> [INFO]   central (http://repo1.maven.org/maven2),
> [INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
> [INFO]
> [INFO] Path to dependency:
> [INFO]  1) test:sample:war:0.1
> [INFO]
> [INFO]
> [INFO]  at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:374)
> [INFO]  at 
> org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
> [INFO]  at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316)
> [INFO]  at 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304)
> [INFO]  at 
> org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1499)
> [INFO]  at 
> org.apache.mav

Re: [Lift] Re: PayPal X

[Timothy Perrett]

Sure, JAXB... im using JAX-WS heavily at work in one of my scala frameworks 
that I wrote for working with a product API... on the whole, its pretty sweet 
with the scala sugar and im bummed that the licensing is not helping us out on 
this front. 

Cheers, Tim

On 22 Dec 2009, at 16:46, Ross Mellgren wrote:

> It's been said ;-)
> 
> At work, I wrote our SOAP integration because as much pain as SOAP is, it's 
> less pain that SOAP + SOAP library, especially Axis (at least at the time, 
> when Axis2 was not out). To this day the only place we use a SOAP library 
> (Axis1, in a client) is broken due to bugs in the SOAP library.
> 
> By simple integration, I mean just throwing  and 
>  around whatever message XML and then using simple xpath-esque 
> expressions to rip it back out.
> 
> JAX-WS is somewhat nicer, it's unfortunate that the licensing seems to be 
> preventing it, although I'm interested how you'd tackle the marshalling -- 
> using JAXB as usual? I haven't used JAXB with Scala, only with Java, so I 
> don't know how well they play together.
> 
> -Ross
> 
> On Dec 22, 2009, at 11:14 AM, Timothy Perrett wrote:
> 
>> Ross, you must be some kind of sadist? ;-) I spend most of my professional 
>> life using SOAP, and im scared for life! Right now I have zero inclination 
>> to write an SOAP library for Scala... its just too painful (soap, not scala) 
>> 
>> Cheers, Tim
>> 
>> On 22 Dec 2009, at 15:49, Ross Mellgren wrote:
>> 
>>> Roll your own? With the amount of XML power scala offers you, it seems like 
>>> for a simple integration it might not be that much effort? Hardly ideal, I 
>>> know. :-/
>>> 
>>> -Ross
>>> 
>>> On Dec 22, 2009, at 3:50 AM, Timothy Perrett wrote:
>>> 
 Doh! Thats not very helpful - CXF depends on JAX-WS, so same problems 
 there. Looks like Apache Axis is AP2 licensed, but I really dont like Axis 
 at all. Any ideas?
 
 Cheers, Tim
 
 On 22 Dec 2009, at 01:04, Ross Mellgren wrote:
 
> Looks like JAX-WS reference implementation is dual licensed CDDL or GPLv2.
> 
> -Ross
> 
> On Dec 21, 2009, at 7:32 PM, David Pollak wrote:
> 
>> 
>> 
>> On Mon, Dec 21, 2009 at 4:28 PM, Timothy Perrett 
>>  wrote:
>> Cool - I'll have a play overthe hols.
>> 
>> It's a SOAP api so I'd need to depend on CXF or JAXWS... Do you forsee
>> any license conflicts before I start work?
>> 
>> As long as those libraries are Apache 2 or MIT/BSD licenses, all is good.
>>  
>> 
>> Cheers, Tim
>> 
>> On Dec 21, 6:58 pm, David Pollak 
>> wrote:
>> > On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett 
>> > wrote:
>> >
>> > > 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.
>> >
>> > I'd love to see you write this Tim. ;-)
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > 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.
>> >
>> > --
>> > Lift, the simply functional web frameworkhttp://liftweb.net
>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > Follow me:http://twitter.com/dpp
>> > Surf the harmonics
>> 
>> --
>> 
>> You received this message because you are subscribed to the Google 
>> Groups "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/liftweb?hl=en.
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>> 
>> --
>> 
>> You received this message because you are subscribed to the Google 
>> Groups "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/liftweb?hl=en.
>>

Re: [Lift] Re: PayPal X

[Ross Mellgren]

It's been said ;-)

At work, I wrote our SOAP integration because as much pain as SOAP is,  
it's less pain that SOAP + SOAP library, especially Axis (at least at  
the time, when Axis2 was not out). To this day the only place we use a  
SOAP library (Axis1, in a client) is broken due to bugs in the SOAP  
library.

By simple integration, I mean just throwing  and  
 around whatever message XML and then using simple  
xpath-esque expressions to rip it back out.

JAX-WS is somewhat nicer, it's unfortunate that the licensing seems to  
be preventing it, although I'm interested how you'd tackle the  
marshalling -- using JAXB as usual? I haven't used JAXB with Scala,  
only with Java, so I don't know how well they play together.

-Ross

On Dec 22, 2009, at 11:14 AM, Timothy Perrett wrote:

> Ross, you must be some kind of sadist? ;-) I spend most of my  
> professional life using SOAP, and im scared for life! Right now I  
> have zero inclination to write an SOAP library for Scala... its just  
> too painful (soap, not scala)
>
> Cheers, Tim
>
> On 22 Dec 2009, at 15:49, Ross Mellgren wrote:
>
>> Roll your own? With the amount of XML power scala offers you, it  
>> seems like for a simple integration it might not be that much  
>> effort? Hardly ideal, I know. :-/
>>
>> -Ross
>>
>> On Dec 22, 2009, at 3:50 AM, Timothy Perrett wrote:
>>
>>> Doh! Thats not very helpful - CXF depends on JAX-WS, so same  
>>> problems there. Looks like Apache Axis is AP2 licensed, but I  
>>> really dont like Axis at all. Any ideas?
>>>
>>> Cheers, Tim
>>>
>>> On 22 Dec 2009, at 01:04, Ross Mellgren wrote:
>>>
 Looks like JAX-WS reference implementation is dual licensed CDDL  
 or GPLv2.

 -Ross

 On Dec 21, 2009, at 7:32 PM, David Pollak wrote:

>
>
> On Mon, Dec 21, 2009 at 4:28 PM, Timothy Perrett  > wrote:
> Cool - I'll have a play overthe hols.
>
> It's a SOAP api so I'd need to depend on CXF or JAXWS... Do you  
> forsee
> any license conflicts before I start work?
>
> As long as those libraries are Apache 2 or MIT/BSD licenses, all  
> is good.
>
>
> Cheers, Tim
>
> On Dec 21, 6:58 pm, David Pollak 
> wrote:
> > On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett  
> wrote:
> >
> > > 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.
> >
> > I'd love to see you write this Tim. ;-)
> >
> >
> >
> >
> >
> >
> >
> > > 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 %2bunsubscr...@googlegroups.com >
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/liftweb?hl=en.
> >
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Beginning Scalahttp://www.apress.com/book/view/1430219890
> > Follow me:http://twitter.com/dpp
> > Surf the harmonics
>
> --
>
> You received this message because you are subscribed to the  
> Google Groups "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com 
> .
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en 
> .
>
>
>
>
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
>
> You received this message because you are subscribed to the  
> Google Groups "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to 
> liftweb+unsubscr...@googlegroups.com 
> .
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en 
> .


 --

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

Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

I just verified that it did indeed use 2.7.7, because the generated
classfiles still have version 4.1.

My new strategy is to build with the last working RC3, and then
recompile just the failing file with the current compiler and all lift
classes on the classpath. That should work.

But I need to know how to build lift with a 2.8.0 compiler. Or
alternatively, if a kind soul can send me a lift 2.8.0 tarball with
all the classfiles in there I can take it from there.

Thanks

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

Thanks for all the help. I tried to do

mvn clean
mvn install

After upgrading to maven 2.2.1, I got somewhere. It compiled a bunch
of packages including lift-mapper, so it seems it did not in fact take
RC6 as its compiler?

But then it stopped due to a build error here.

Any idea what I need to do to solve this?

Thanks

 -- martin



[INFO] [INFO] 

[INFO] [ERROR] BUILD ERROR
[INFO] [INFO] 

[INFO] [INFO] Failed to resolve artifact.
[INFO]
[INFO] Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19,
6.1.20, 6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]
[INFO] [INFO] 

[INFO] [INFO] Trace
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException:
Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20,
6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
[INFO]  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
[INFO]  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
[INFO]  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
[INFO]  at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
[INFO]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[INFO]  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[INFO]  at java.lang.reflect.Method.invoke(Method.java:597)
[INFO]  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
[INFO]  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
[INFO]  at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
[INFO]  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] Caused by:
org.apache.maven.artifact.versioning.OverConstrainedVersionException:
Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20,
6.1.21, 6.1.22] to match range [6.1.6,6.1.6]
[INFO]   org.mortbay.jetty:jetty:jar:null
[INFO]
[INFO] from the specified remote repositories:
[INFO]   scala-tools.org (http://scala-tools.org/repo-releases),
[INFO]   central (http://repo1.maven.org/maven2),
[INFO]   scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots)
[INFO]
[INFO] Path to dependency:
[INFO]  1) test:sample:war:0.1
[INFO]
[INFO]
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:374)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316)
[INFO]  at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304)
[INFO]  at 
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1499)
[INFO]  at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442)
[INFO]  at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
[INFO]  ... 17 more
[INFO] [INFO] 

[INFO] [INFO] Total time: 6 seconds
[INFO] [INFO] Finished at: Tue Dec 22 17:26:55 CET 2009
[INFO] [INFO] Final Memory: 12M/127M
[INFO] [INFO] 
--

Re: [Lift] The future of lift-core

[Indrajit Raychaudhuri]

On 22/12/09 12:23 AM, David Pollak wrote:
>
>
> On Sun, Dec 20, 2009 at 11:39 AM, Indrajit Raychaudhuri
> mailto:indraj...@gmail.com>> wrote:
>
> 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,
>
>
> Lift 2.0 is not "coming up" it's merely a rename of Lift 1.1 based on
> the naming rules that Heiko proposed and the Lift community adopted.
> The fact that the next release of Lift is going to be called 2.0 rather
> than 1.1 does not change the scope of the release.

Indeed, poor wordings, Lift 2.0 *restructure* coming up is what I meant. 
But yes, it ends up sounding different, sorry.

>
> With that being said, deprecating lift-core is fine by me as long as
> there is an easy to understand deprecation message with clear
> instructions as to how to replace lift-core with whatever is necessary.

For deprecating dependencies, it's just matter of persuasion 
(Announcement, wiki etc.) for at least two releases, or more (could be 
milestone releases). And eventually, dropping it from the build beyond 
an agreeable release time frame.

I couldn't figure out a clean way of deprecating 'meta' packages since 
it doesn't have any active code (thus doesn't expose any place to code 
in some deprecation warning message).

As such, the package is harmless and there is zero cost of maintenance. 
Just that, it's no more a good practice (longer build time, larger war 
size etc.).

>
> 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 liftweb@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 simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.

--

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: PayPal X

[Timothy Perrett]

Ross, you must be some kind of sadist? ;-) I spend most of my professional life 
using SOAP, and im scared for life! Right now I have zero inclination to write 
an SOAP library for Scala... its just too painful (soap, not scala) 

Cheers, Tim

On 22 Dec 2009, at 15:49, Ross Mellgren wrote:

> Roll your own? With the amount of XML power scala offers you, it seems like 
> for a simple integration it might not be that much effort? Hardly ideal, I 
> know. :-/
> 
> -Ross
> 
> On Dec 22, 2009, at 3:50 AM, Timothy Perrett wrote:
> 
>> Doh! Thats not very helpful - CXF depends on JAX-WS, so same problems there. 
>> Looks like Apache Axis is AP2 licensed, but I really dont like Axis at all. 
>> Any ideas?
>> 
>> Cheers, Tim
>> 
>> On 22 Dec 2009, at 01:04, Ross Mellgren wrote:
>> 
>>> Looks like JAX-WS reference implementation is dual licensed CDDL or GPLv2.
>>> 
>>> -Ross
>>> 
>>> On Dec 21, 2009, at 7:32 PM, David Pollak wrote:
>>> 
 
 
 On Mon, Dec 21, 2009 at 4:28 PM, Timothy Perrett  
 wrote:
 Cool - I'll have a play overthe hols.
 
 It's a SOAP api so I'd need to depend on CXF or JAXWS... Do you forsee
 any license conflicts before I start work?
 
 As long as those libraries are Apache 2 or MIT/BSD licenses, all is good.
  
 
 Cheers, Tim
 
 On Dec 21, 6:58 pm, David Pollak 
 wrote:
 > On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett 
 > wrote:
 >
 > > 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.
 >
 > I'd love to see you write this Tim. ;-)
 >
 >
 >
 >
 >
 >
 >
 > > 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.
 >
 > --
 > Lift, the simply functional web frameworkhttp://liftweb.net
 > Beginning Scalahttp://www.apress.com/book/view/1430219890
 > Follow me:http://twitter.com/dpp
 > Surf the harmonics
 
 --
 
 You received this message because you are subscribed to the Google Groups 
 "Lift" group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
 
 
 
 
 
 -- 
 Lift, the simply functional web framework http://liftweb.net
 Beginning Scala http://www.apress.com/book/view/1430219890
 Follow me: http://twitter.com/dpp
 Surf the harmonics
 
 --
 
 You received this message because you are subscribed to the Google Groups 
 "Lift" group.
 To post to this group, send email to lift...@googlegroups.com.
 To unsubscribe from this group, send email to 
 liftweb+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/liftweb?hl=en.
>>> 
>>> 
>>> --
>>> 
>>> 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.
> 
> 
> --
> 
> 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.co

Re: [Lift] Re: PayPal X

[Ross Mellgren]

Roll your own? With the amount of XML power scala offers you, it seems  
like for a simple integration it might not be that much effort? Hardly  
ideal, I know. :-/

-Ross

On Dec 22, 2009, at 3:50 AM, Timothy Perrett wrote:

> Doh! Thats not very helpful - CXF depends on JAX-WS, so same  
> problems there. Looks like Apache Axis is AP2 licensed, but I really  
> dont like Axis at all. Any ideas?
>
> Cheers, Tim
>
> On 22 Dec 2009, at 01:04, Ross Mellgren wrote:
>
>> Looks like JAX-WS reference implementation is dual licensed CDDL or  
>> GPLv2.
>>
>> -Ross
>>
>> On Dec 21, 2009, at 7:32 PM, David Pollak wrote:
>>
>>>
>>>
>>> On Mon, Dec 21, 2009 at 4:28 PM, Timothy Perrett >> > wrote:
>>> Cool - I'll have a play overthe hols.
>>>
>>> It's a SOAP api so I'd need to depend on CXF or JAXWS... Do you  
>>> forsee
>>> any license conflicts before I start work?
>>>
>>> As long as those libraries are Apache 2 or MIT/BSD licenses, all  
>>> is good.
>>>
>>>
>>> Cheers, Tim
>>>
>>> On Dec 21, 6:58 pm, David Pollak 
>>> wrote:
>>> > On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett  
>>> wrote:
>>> >
>>> > > 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.
>>> >
>>> > I'd love to see you write this Tim. ;-)
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > > 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>> %2bunsubscr...@googlegroups.com >
>>> > > .
>>> > > For more options, visit this group at
>>> > >http://groups.google.com/group/liftweb?hl=en.
>>> >
>>> > --
>>> > Lift, the simply functional web frameworkhttp://liftweb.net
>>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>>> > Follow me:http://twitter.com/dpp
>>> > Surf the harmonics
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google  
>>> Groups "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> liftweb+unsubscr...@googlegroups.com 
>>> .
>>> For more options, visit this group at 
>>> http://groups.google.com/group/liftweb?hl=en 
>>> .
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> Lift, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Surf the harmonics
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google  
>>> Groups "Lift" group.
>>> To post to this group, send email to lift...@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> liftweb+unsubscr...@googlegroups.com 
>>> .
>>> For more options, visit this group at 
>>> http://groups.google.com/group/liftweb?hl=en 
>>> .
>>
>>
>> --
>>
>> 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 
> .

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Indrajit Raychaudhuri]

Ok, this one works just fine, and involves least effort among the ones 
proposed.

- Indrajit

On 22/12/09 8:11 PM, Heiko Seeberger wrote:
> Martin,
>
> OK, now I got it working (almost) without Maven:
>
> 1. step:
> Check out 280_port branch from g...@github.com:dpp/liftweb.git
>
> 2. step:
> cd into liftweb/lift-persistence/lift-mapper and run
> mvn dependency:copy-dependencies
>
> 3. step:
> run the following command
>  -classpath `find target/dependency
> -name *.jar | xargs scala -e 'println(args mkString ":")'` -sourcepath
> src/main/scala -d target/classes `find src/main/scala -name *.scala`
>
> This will only use Maven to download the dependencies, but you can
> compile with scalac or fsc.
>
> Heiko
>
> --
>
> 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: [maven-and-scala] Re: Nexus/Hudson maitenance on scala-tools.org

[Indrajit Raychaudhuri]

No problem, Josh. "build nodes" approach is certainly _the_ approach in 
the long term. More flexibility, better load distribution, etc.

Thanks again for the upgrade job!

Cheers, Indrajit

On 21/12/09 11:36 PM, Josh Suereth wrote:
> Deferred for now.  I was trying to figure out how to set up "build
> nodes" which would handle building against various platforms (e.g.
> windows, mac, ubuntu, fedora, etc.).   This is where we could better
> customize what's installed on our "build farm".  Might take a different
> approach short term, but this is where we'd like to take it long term.
>
> - Josh
>
>
>
> On Mon, Dec 21, 2009 at 9:38 AM, Indrajit Raychaudhuri
> mailto:indraj...@gmail.com>> wrote:
>
> Neato! Thank you very much for the upgrade and the update on that!
>
> Should we expect a java5 environment as well, or are you deferring this
> for now?
>
> Cheers, Indrajit
>
> On 21/12/09 7:44 PM, Josh Suereth wrote:
>  > The hudson upgrade has been completed, however the nexus upgrade ran
>  > into some issues.  We've reverted to the previous version of nexus.
>  > There will be a continuing maintenance window (for nexus only)
> from 8pm
>  > - 11pm EST today (December 21st).
>  >
>  > Thanks for your patience!
>  > - Josh Suereth
>  >
>  > On Fri, Dec 18, 2009 at 3:38 PM, Josh Suereth
> mailto:joshua.suer...@gmail.com>
>  >  >> wrote:
>  >
>  > All,
>  >
>  > Nexus/Hudson will be temporarily disabled Saturday/Sunday  from
>  > 8-11pm  EST.   These services are being upgraded.   I'll post an
>  > email 15 minutes before the actual shutdown and immediately after
>  > things are back up and working.  You should be able to make
> use of
>  > artifacts on the scala-tools.org 
>  server,
>  > however nightly builds and posting releases will be disabled.  If
>  > anyone has a specific release/test they need performed during
> this
>  > period please send me an email and I can accomodate you.
>  >
>  >
>  > Thanks for your cooperation!
>  >
>  > - Josh Suereth
>  >
>  >
>  >
>  >
>
> --
>
> 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
> .
> 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.

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Indrajit Raychaudhuri]

Martin/Heiko,

Great if this works.

Alternately, you can also use maven ant plugin to complete avoid doing 
the Maven way.

Here is the sequence:

1. Do "mvn ant:ant" at the top level. This should generate all the 
requisite files necessary for ant build.

2. Look for the pathelement entry in maven-build.xml that is generated 
(at the same level as pom.xml)

3. In that file, find the classpath entry for scala-library
(something like: 

4. Replace that jar with the jar that is being generated out of scala build

5. Do 'ant compile' for compiling ('ant -p' would should the list of 
commands)

Thanks, Indrajit


On 22/12/09 8:32 PM, Heiko Seeberger wrote:
> 2009/12/22 martin odersky  >
>
>
> Great! Can you provide me with a tarball or zip of the lift sources? I
> don't have git installed here yet.
>
>
> Please find attached the relevant part of the sources.
>
> 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.

--

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] RC5 candidate for the first 2.8.0 beta

[David Pollak]

Martin,

You can download a tarball from:
http://github.com/dpp/liftweb/tree/280_port/

Go to that page and look for the "download" button.  You'll be presented
with the option of tar or zip.

I'll also send you the tarball privately.

Thanks,

David

On Tue, Dec 22, 2009 at 5:12 AM, martin odersky wrote:

> On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth 
> wrote:
> > I think staying in maven would require the least amount of typing, but
> the
> > most amount of time as you'd have to publish local snapshots of Scala
> 2.8.0
> > to use them in the lift build.  I remember how annoying this is ;).
> Also
> > note that deploying maven requires a full scala build, but if needed I
> can
> > make a short-cut that will just publish the "quick" libraries.  This
> would
> > help immensely in testing trunk against projects, but is not very helpful
> > otherwise.  Would this be desirable?
> >
> > What was already suggested (runing mvn dependency:copy-dependencies) is
> very
> > viable.   However, if lift-mapper relies on lift-util, you'll have to
> > rebuild one before you rebuild the other if you're somehow changing the
> ABI.
> >
> > If you still wanted to use maven, I recommend using the reactor plugin.
> If
> > you identify the project that is failing you can run:
> >
> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper
> >
> > Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the
> > failing module.  This will only build the lift-mapper module and other
> > modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util
> > (and only lift-util) just those two will be built.
> >
> > I have a local VM where I was setting up a scala nightly build that would
> > feed maven.  Perhaps when I finish I'll make a write-up on how to do
> this,
> > or have some kind of template/script you can use to do it by hand.
> >
> > - Josh
> >
> Hi Josh,
>
> The problem is not so much building individual maven modules, but
> building them with experimental compilers. I need to be able to put a
> println into scalac, rebuild that (takes 10sec with fsc) and then
> recompile the offending maven part with that compiler. That's why I
> need a version of lift that can be compiled without maven. It need not
> be perfect, for instance one can probably throw out all the tests. But
> I need to be able to use lift as a rapid experimentation tool for the
> scala compiler itself.
>
> Unfortunately, LAMP is pretty much shutting down for the holidays
> right now. So any outside help that you can give is appreciated.
> Ideally: I get the right lift version as a tarball, together with all
> jars that it needs. Then, instructions what to compile in what order
> (I can probably figure them out in a pinch, but if someone knows that
> already, it would help).
>
> Thanks
>
>  -- Martin
>



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta

[David Bernard]

Kevin,

maven-scala-plugin integrate a workaround (see note of previous mail)
against the line-length limit : arguments of the main class are store in a
file.

/davidB

On Tue, Dec 22, 2009 at 15:45, Kevin Wright
wrote:

>
>
> 2009/12/22 David Bernard 
>
> Dirty solutions (If you already have maven installed and be able to build
>> lift with maven) :
>>
>> 0. replace
>> $HOME/.m2/repository/org/scala-lang/scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar
>> by symlink to the directory with classes result from scalac scalac
>> compilation
>>
>> 1. Or at the end of scalac scalac compilation create a jar and copy
>> (override) t in place of
>> .m2//scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar
>>
>> 2. Or you could run maven with the -Dmaven.scala.displayCmd=true then the
>> command line used to build will be displayed.
>> Copy the line into a .sh/.cmd
>> Modifie the location scala .jar to use the output of your scalac scalac
>> compilation.
>>
>
>
> The catch here is if there's a line-length limit in your OS - the classpath
> gets truncated and then it all goes pear-shaped...
>
>
>
>> Notes :
>> * the call of scalac is wrapped into a main able to handle a long list of
>> arguments from file (working with any version of scala).
>> * maven-scala-plugin was created to used classes (scalac) packaged into
>> jar
>>
>> Sorry to not provide a better solution.
>>
>> /davidB
>>
>> On Tue, Dec 22, 2009 at 15:16, martin odersky wrote:
>>
>>> On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth 
>>> wrote:
>>> > For curiousities sake, if you're building using fsc, are you running
>>> scalac
>>> > via an exploded classpath (i.e. not a JAR file?).  If so, I'll try to
>>> come
>>> > up with a longer-term solution for this.
>>>
>>> Yes, exactly. My usual setup is that my output directory is the first
>>> item on the classpath. So any files I recompile get chosen first.
>>>
>>> >
>>> > If we allowed you to do the following:
>>> >
>>> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P
>>> local-scala
>>> > -Dscala.local.classpath=classfiledir
>>> >
>>> > would that be sufficient?  We could also have this do conditional
>>> > computation in the future.
>>>
>>> Does that mean that the scala compiler would then be run out of
>>> classfiledir? Yes, that could work.
>>>
>>> Cheers
>>>
>>>  -- Martin
>>>
>>> --
>>>
>>> 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.
>>
>
>
>
> --
> Kevin Wright
>
> mail/google talk: kev.lee.wri...@googlemail.com
> wave: kev.lee.wri...@googlewave.com
> skype: kev.lee.wright
> twitter: @thecoda
>
>  --
> 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

On Tue, Dec 22, 2009 at 3:41 PM, Heiko Seeberger
 wrote:
> Martin,
> OK, now I got it working (almost) without Maven:
> 1. step:
> Check out 280_port branch from ...@github.com:dpp/liftweb.git
> 2. step:
> cd into liftweb/lift-persistence/lift-mapper and run
> mvn dependency:copy-dependencies
> 3. step:
> run the following command
>  -classpath `find target/dependency
> -name *.jar | xargs scala -e 'println(args mkString ":")'` -sourcepath
> src/main/scala -d target/classes `find src/main/scala -name *.scala`
> This will only use Maven to download the dependencies, but you can compile
> with scalac or fsc.

Great! Can you provide me with a tarball or zip of the lift sources? I
don't have git installed here yet.

Thanks

 -- Martin

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[Kevin Wright]

2009/12/22 David Bernard 

> Dirty solutions (If you already have maven installed and be able to build
> lift with maven) :
>
> 0. replace
> $HOME/.m2/repository/org/scala-lang/scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar
> by symlink to the directory with classes result from scalac scalac
> compilation
>
> 1. Or at the end of scalac scalac compilation create a jar and copy
> (override) t in place of
> .m2//scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar
>
> 2. Or you could run maven with the -Dmaven.scala.displayCmd=true then the
> command line used to build will be displayed.
> Copy the line into a .sh/.cmd
> Modifie the location scala .jar to use the output of your scalac scalac
> compilation.
>


The catch here is if there's a line-length limit in your OS - the classpath
gets truncated and then it all goes pear-shaped...



> Notes :
> * the call of scalac is wrapped into a main able to handle a long list of
> arguments from file (working with any version of scala).
> * maven-scala-plugin was created to used classes (scalac) packaged into jar
>
> Sorry to not provide a better solution.
>
> /davidB
>
> On Tue, Dec 22, 2009 at 15:16, martin odersky wrote:
>
>> On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth 
>> wrote:
>> > For curiousities sake, if you're building using fsc, are you running
>> scalac
>> > via an exploded classpath (i.e. not a JAR file?).  If so, I'll try to
>> come
>> > up with a longer-term solution for this.
>>
>> Yes, exactly. My usual setup is that my output directory is the first
>> item on the classpath. So any files I recompile get chosen first.
>>
>> >
>> > If we allowed you to do the following:
>> >
>> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala
>> > -Dscala.local.classpath=classfiledir
>> >
>> > would that be sufficient?  We could also have this do conditional
>> > computation in the future.
>>
>> Does that mean that the scala compiler would then be run out of
>> classfiledir? Yes, that could work.
>>
>> Cheers
>>
>>  -- Martin
>>
>> --
>>
>> 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.
>



-- 
Kevin Wright

mail/google talk: kev.lee.wri...@googlemail.com
wave: kev.lee.wri...@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--

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] RC5 candidate for the first 2.8.0 beta

[Heiko Seeberger]

Martin,

OK, now I got it working (almost) without Maven:

1. step:
Check out 280_port branch from g...@github.com:dpp/liftweb.git

2. step:
cd into liftweb/lift-persistence/lift-mapper and run
mvn dependency:copy-dependencies

3. step:
run the following command
 -classpath `find target/dependency
-name *.jar | xargs scala -e 'println(args mkString ":")'` -sourcepath
src/main/scala -d target/classes `find src/main/scala -name *.scala`

This will only use Maven to download the dependencies, but you can compile
with scalac or fsc.

Heiko

--

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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[David Bernard]

Dirty solutions (If you already have maven installed and be able to build
lift with maven) :

0. replace
$HOME/.m2/repository/org/scala-lang/scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar
by symlink to the directory with classes result from scalac scalac
compilation

1. Or at the end of scalac scalac compilation create a jar and copy
(override) t in place of
.m2//scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar

2. Or you could run maven with the -Dmaven.scala.displayCmd=true then the
command line used to build will be displayed.
Copy the line into a .sh/.cmd
Modifie the location scala .jar to use the output of your scalac scalac
compilation.

Notes :
* the call of scalac is wrapped into a main able to handle a long list of
arguments from file (working with any version of scala).
* maven-scala-plugin was created to used classes (scalac) packaged into jar

Sorry to not provide a better solution.

/davidB

On Tue, Dec 22, 2009 at 15:16, martin odersky wrote:

> On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth 
> wrote:
> > For curiousities sake, if you're building using fsc, are you running
> scalac
> > via an exploded classpath (i.e. not a JAR file?).  If so, I'll try to
> come
> > up with a longer-term solution for this.
>
> Yes, exactly. My usual setup is that my output directory is the first
> item on the classpath. So any files I recompile get chosen first.
>
> >
> > If we allowed you to do the following:
> >
> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala
> > -Dscala.local.classpath=classfiledir
> >
> > would that be sufficient?  We could also have this do conditional
> > computation in the future.
>
> Does that mean that the scala compiler would then be run out of
> classfiledir? Yes, that could work.
>
> Cheers
>
>  -- Martin
>
> --
>
> 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: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth  wrote:
> For curiousities sake, if you're building using fsc, are you running scalac
> via an exploded classpath (i.e. not a JAR file?).  If so, I'll try to come
> up with a longer-term solution for this.

Yes, exactly. My usual setup is that my output directory is the first
item on the classpath. So any files I recompile get chosen first.

>
> If we allowed you to do the following:
>
> mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala
> -Dscala.local.classpath=classfiledir
>
> would that be sufficient?  We could also have this do conditional
> computation in the future.

Does that mean that the scala compiler would then be run out of
classfiledir? Yes, that could work.

Cheers

 -- Martin

--

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] RC5 candidate for the first 2.8.0 beta

[Kevin Wright]

Another possibility is to specify scala as a system dependency in Lift's
pom:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies

Then hard code the path that scalac's being built into.
put maven in offline mode as well, and it should be nice and quick.


2009/12/22 Josh Suereth 

> For curiousities sake, if you're building using fsc, are you running scalac
> via an exploded classpath (i.e. not a JAR file?).  If so, I'll try to come
> up with a longer-term solution for this.
>
> If we allowed you to do the following:
>
> mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala
> -Dscala.local.classpath=classfiledir
>
> would that be sufficient?  We could also have this do conditional
> computation in the future.
>
> - Josh
>
>
> On Tue, Dec 22, 2009 at 8:12 AM, martin odersky wrote:
>
>> On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth 
>> wrote:
>> > I think staying in maven would require the least amount of typing, but
>> the
>> > most amount of time as you'd have to publish local snapshots of Scala
>> 2.8.0
>> > to use them in the lift build.  I remember how annoying this is ;).
>> Also
>> > note that deploying maven requires a full scala build, but if needed I
>> can
>> > make a short-cut that will just publish the "quick" libraries.  This
>> would
>> > help immensely in testing trunk against projects, but is not very
>> helpful
>> > otherwise.  Would this be desirable?
>> >
>> > What was already suggested (runing mvn dependency:copy-dependencies) is
>> very
>> > viable.   However, if lift-mapper relies on lift-util, you'll have to
>> > rebuild one before you rebuild the other if you're somehow changing the
>> ABI.
>> >
>> > If you still wanted to use maven, I recommend using the reactor
>> plugin.   If
>> > you identify the project that is failing you can run:
>> >
>> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper
>> >
>> > Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the
>> > failing module.  This will only build the lift-mapper module and other
>> > modules on which lift-mapper depends (i.e. if lift-mapper needs
>> lift-util
>> > (and only lift-util) just those two will be built.
>> >
>> > I have a local VM where I was setting up a scala nightly build that
>> would
>> > feed maven.  Perhaps when I finish I'll make a write-up on how to do
>> this,
>> > or have some kind of template/script you can use to do it by hand.
>> >
>> > - Josh
>> >
>> Hi Josh,
>>
>> The problem is not so much building individual maven modules, but
>> building them with experimental compilers. I need to be able to put a
>> println into scalac, rebuild that (takes 10sec with fsc) and then
>> recompile the offending maven part with that compiler. That's why I
>> need a version of lift that can be compiled without maven. It need not
>> be perfect, for instance one can probably throw out all the tests. But
>> I need to be able to use lift as a rapid experimentation tool for the
>> scala compiler itself.
>>
>> Unfortunately, LAMP is pretty much shutting down for the holidays
>> right now. So any outside help that you can give is appreciated.
>> Ideally: I get the right lift version as a tarball, together with all
>> jars that it needs. Then, instructions what to compile in what order
>> (I can probably figure them out in a pinch, but if someone knows that
>> already, it would help).
>>
>> Thanks
>>
>>  -- Martin
>>
>
>


-- 
Kevin Wright

mail/google talk: kev.lee.wri...@googlemail.com
wave: kev.lee.wri...@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

--

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] RC5 candidate for the first 2.8.0 beta

[Josh Suereth]

For curiousities sake, if you're building using fsc, are you running scalac
via an exploded classpath (i.e. not a JAR file?).  If so, I'll try to come
up with a longer-term solution for this.

If we allowed you to do the following:

mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala
-Dscala.local.classpath=classfiledir

would that be sufficient?  We could also have this do conditional
computation in the future.

- Josh

On Tue, Dec 22, 2009 at 8:12 AM, martin odersky wrote:

> On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth 
> wrote:
> > I think staying in maven would require the least amount of typing, but
> the
> > most amount of time as you'd have to publish local snapshots of Scala
> 2.8.0
> > to use them in the lift build.  I remember how annoying this is ;).
> Also
> > note that deploying maven requires a full scala build, but if needed I
> can
> > make a short-cut that will just publish the "quick" libraries.  This
> would
> > help immensely in testing trunk against projects, but is not very helpful
> > otherwise.  Would this be desirable?
> >
> > What was already suggested (runing mvn dependency:copy-dependencies) is
> very
> > viable.   However, if lift-mapper relies on lift-util, you'll have to
> > rebuild one before you rebuild the other if you're somehow changing the
> ABI.
> >
> > If you still wanted to use maven, I recommend using the reactor plugin.
> If
> > you identify the project that is failing you can run:
> >
> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper
> >
> > Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the
> > failing module.  This will only build the lift-mapper module and other
> > modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util
> > (and only lift-util) just those two will be built.
> >
> > I have a local VM where I was setting up a scala nightly build that would
> > feed maven.  Perhaps when I finish I'll make a write-up on how to do
> this,
> > or have some kind of template/script you can use to do it by hand.
> >
> > - Josh
> >
> Hi Josh,
>
> The problem is not so much building individual maven modules, but
> building them with experimental compilers. I need to be able to put a
> println into scalac, rebuild that (takes 10sec with fsc) and then
> recompile the offending maven part with that compiler. That's why I
> need a version of lift that can be compiled without maven. It need not
> be perfect, for instance one can probably throw out all the tests. But
> I need to be able to use lift as a rapid experimentation tool for the
> scala compiler itself.
>
> Unfortunately, LAMP is pretty much shutting down for the holidays
> right now. So any outside help that you can give is appreciated.
> Ideally: I get the right lift version as a tarball, together with all
> jars that it needs. Then, instructions what to compile in what order
> (I can probably figure them out in a pinch, but if someone knows that
> already, it would help).
>
> Thanks
>
>  -- Martin
>

--

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: Catch file upload exceptions?

[tiro]

Hi Tim,

thanks for raising this, I did wrap the whole thing like so:


LiftRules.maxMimeSize = 6 * 1024 * 1024
LiftRules.maxMimeFileSize = 5 * 1024 * 1024

LiftRules.handleMimeFile = (fieldName, contentType, fileName,
inputStream) =>  {
  try {
OnDiskFileParamHolder(fieldName, contentType, fileName,
inputStream)
  }
  catch {
case e:Exception =>
  S.error("Failure in upload (file too large?). Details: " +
e.toString)
  new InMemFileParamHolder("", "", "", null)
case _ => new InMemFileParamHolder("", "", "", null)
  }
}

and now I remember that I did manage to catch an exception once when I
set the maxMimeFileSize to very low. Then I set it back to where it
was and tested with a 7MB file.
I think I understand now: The above will catch based on
maxMimeFileSize. It will not work when the file you upload also
exceeds the maxMimeSize, which is when you get the stack trace at the
beginning of my post.

So I suppose the solution is to set the maxMimeSize to "Infinity".

Marius, thanks for the hint. Was just a quick idea how to keep face
with users in such a case, since I'm running on a virtual server, but
it's clear such conditions should really be avoided by proper
configuration and load testing.

Best wishes, 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.

[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta

[martin odersky]

On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth  wrote:
> I think staying in maven would require the least amount of typing, but the
> most amount of time as you'd have to publish local snapshots of Scala 2.8.0
> to use them in the lift build.  I remember how annoying this is ;).   Also
> note that deploying maven requires a full scala build, but if needed I can
> make a short-cut that will just publish the "quick" libraries.  This would
> help immensely in testing trunk against projects, but is not very helpful
> otherwise.  Would this be desirable?
>
> What was already suggested (runing mvn dependency:copy-dependencies) is very
> viable.   However, if lift-mapper relies on lift-util, you'll have to
> rebuild one before you rebuild the other if you're somehow changing the ABI.
>
> If you still wanted to use maven, I recommend using the reactor plugin.   If
> you identify the project that is failing you can run:
>
> mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper
>
> Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the
> failing module.  This will only build the lift-mapper module and other
> modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util
> (and only lift-util) just those two will be built.
>
> I have a local VM where I was setting up a scala nightly build that would
> feed maven.  Perhaps when I finish I'll make a write-up on how to do this,
> or have some kind of template/script you can use to do it by hand.
>
> - Josh
>
Hi Josh,

The problem is not so much building individual maven modules, but
building them with experimental compilers. I need to be able to put a
println into scalac, rebuild that (takes 10sec with fsc) and then
recompile the offending maven part with that compiler. That's why I
need a version of lift that can be compiled without maven. It need not
be perfect, for instance one can probably throw out all the tests. But
I need to be able to use lift as a rapid experimentation tool for the
scala compiler itself.

Unfortunately, LAMP is pretty much shutting down for the holidays
right now. So any outside help that you can give is appreciated.
Ideally: I get the right lift version as a tarball, together with all
jars that it needs. Then, instructions what to compile in what order
(I can probably figure them out in a pinch, but if someone knows that
already, it would help).

Thanks

 -- Martin

--

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] RC5 candidate for the first 2.8.0 beta

[Josh Suereth]

I think staying in maven would require the least amount of typing, but the
most amount of time as you'd have to publish local snapshots of Scala 2.8.0
to use them in the lift build.  I remember how annoying this is ;).   Also
note that deploying maven requires a full scala build, but if needed I can
make a short-cut that will just publish the "quick" libraries.  This would
help immensely in testing trunk against projects, but is not very helpful
otherwise.  Would this be desirable?

What was already suggested (runing mvn dependency:copy-dependencies) is very
viable.   However, if lift-mapper relies on lift-util, you'll have to
rebuild one before you rebuild the other if you're somehow changing the ABI.

If you still wanted to use maven, I recommend using the reactor plugin.   If
you identify the project that is failing you can run:

mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper

Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the
failing module.  This will only build the lift-mapper module and other
modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util
(and only lift-util) just those two will be built.

I have a local VM where I was setting up a scala nightly build that would
feed maven.  Perhaps when I finish I'll make a write-up on how to do this,
or have some kind of template/script you can use to do it by hand.

- Josh




On Tue, Dec 22, 2009 at 7:24 AM, David Pollak  wrote:

> I'm cc'ing this to the Lift list.  Perhaps Indrajit or another Maven guru
> can help out.
>
>
> On Tue, Dec 22, 2009 at 2:32 AM, martin odersky wrote:
>
>> On Tue, Dec 22, 2009 at 11:11 AM, Heiko Seeberger
>>  wrote:
>> > 2009/12/22 martin odersky 
>> >>
>> >> Annoying... Just to explain what goes on here. Between RC3 and RC4 we
>> >> tightened the erasure of compund types
>> >> T with U where T and U are traits. These used to be all erased to
>> >> Object and now are erased to the first trait in the sequence, i.e. T
>> >> in the example above. Unfortunately it seems the previous behavior of
>> >> erasing to Object hid a few bugs in prior transformation phases where
>> >> one should have taken the self type of a class and one took instead
>> >> the type of the class itself. These bugs are now crawling out, and it
>> >> seems that lift is their primary crawling ground, probably because of
>> >> its ubiquitous pattern of using self types that are compound types of
>> >> traits.
>> >
>> > Making them creep out sooner than later is beneficial, even if it causes
>> > some pain right now ;-)
>> >
>> >>
>> >> Another problem is that lift by itself is hard to test for me because
>> >> it requires maven (and I am no maven expert) and maven requires a full
>> >> build, which takes time to do. So the turn around time is quite high,
>> >> many hours to days instead of minutes. Any ideas what one can do to
>> >> address these issues would be welcome.
>> >
>> > Meanwhile Lift is a large and highly modular framework. The RC4 error
>> > occurred while building lift-util which is a prerequisite module (built
>> in
>> > the very beginning). The RC5 error occurred while building lift-mapper,
>> > which is already outside of the lift-base modules. Hence I am optimistic
>> > that we do not need many further rounds.
>> > Heiko
>>
>> Is there a way I can build lift from the command line, using simple
>> invocations of scalac only?
>> I don't mind to do it bit by bit. I could isolate the previous fault
>> myself, but for this one it looks like I need help because the file
>> causing the crash depends on too many other things.
>>
>>  -- Martin
>>
>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Re: [Lift] accessing Glassfish javamail through jndi

[David Pollak]

On Tue, Dec 22, 2009 at 4:35 AM, Sandeep  wrote:

> hi guys,
>   Just starting out with the lift framework.
> My intention is to get lift webapps working within glassfish app
> server.
>
> I wanted to know whether it is possible to access a Glassfish javamail
> configuration (say, using Gmail -
>
> http://groups.google.com/group/oop_programming/browse_thread/thread/f2df17c480e45369
> ) from within lift and send mail through it.
>
> I have seen and am aware of the Mailer class and the sendMail method
> (http://scala-blogs.org/2008/06/emailing-and-texting-with-scala-
> lift.html)
>  , but what I want to do is access the Glassfish config and
> use it.
>

If the mailer in Glassfish is available via JNDI, please put the following
in your Boot.scala file:

Mailer.jndiName = Full("path/to/jndi/mailer/resource")

Lift will look up the JNDI resource within Lift's Mailer object and use that
resource.

Thanks,

David


>
> thanks!
> -Sandeep
>
> --
>
> 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 simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: accessing Glassfish javamail through jndi

[Marius]

Well, you can do it from Lift just as you would have done it from Java
code.

Br's,
Marius

On Dec 22, 2:35 pm, Sandeep  wrote:
> hi guys,
>            Just starting out with the lift framework.
> My intention is to get lift webapps working within glassfish app
> server.
>
> I wanted to know whether it is possible to access a Glassfish javamail
> configuration (say, using Gmail 
> -http://groups.google.com/group/oop_programming/browse_thread/thread/f...
> ) from within lift and send mail through it.
>
> I have seen and am aware of the Mailer class and the sendMail method
> (http://scala-blogs.org/2008/06/emailing-and-texting-with-scala-
> lift.html ) , but what I want to do is access the Glassfish config and
> use it.
>
> thanks!
> -Sandeep

--

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] accessing Glassfish javamail through jndi

[Sandeep]

hi guys,
   Just starting out with the lift framework.
My intention is to get lift webapps working within glassfish app
server.

I wanted to know whether it is possible to access a Glassfish javamail
configuration (say, using Gmail -
http://groups.google.com/group/oop_programming/browse_thread/thread/f2df17c480e45369
) from within lift and send mail through it.

I have seen and am aware of the Mailer class and the sendMail method
(http://scala-blogs.org/2008/06/emailing-and-texting-with-scala-
lift.html ) , but what I want to do is access the Glassfish config and
use it.

thanks!
-Sandeep

--

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] RC5 candidate for the first 2.8.0 beta

[David Pollak]

I'm cc'ing this to the Lift list.  Perhaps Indrajit or another Maven guru
can help out.

On Tue, Dec 22, 2009 at 2:32 AM, martin odersky wrote:

> On Tue, Dec 22, 2009 at 11:11 AM, Heiko Seeberger
>  wrote:
> > 2009/12/22 martin odersky 
> >>
> >> Annoying... Just to explain what goes on here. Between RC3 and RC4 we
> >> tightened the erasure of compund types
> >> T with U where T and U are traits. These used to be all erased to
> >> Object and now are erased to the first trait in the sequence, i.e. T
> >> in the example above. Unfortunately it seems the previous behavior of
> >> erasing to Object hid a few bugs in prior transformation phases where
> >> one should have taken the self type of a class and one took instead
> >> the type of the class itself. These bugs are now crawling out, and it
> >> seems that lift is their primary crawling ground, probably because of
> >> its ubiquitous pattern of using self types that are compound types of
> >> traits.
> >
> > Making them creep out sooner than later is beneficial, even if it causes
> > some pain right now ;-)
> >
> >>
> >> Another problem is that lift by itself is hard to test for me because
> >> it requires maven (and I am no maven expert) and maven requires a full
> >> build, which takes time to do. So the turn around time is quite high,
> >> many hours to days instead of minutes. Any ideas what one can do to
> >> address these issues would be welcome.
> >
> > Meanwhile Lift is a large and highly modular framework. The RC4 error
> > occurred while building lift-util which is a prerequisite module (built
> in
> > the very beginning). The RC5 error occurred while building lift-mapper,
> > which is already outside of the lift-base modules. Hence I am optimistic
> > that we do not need many further rounds.
> > Heiko
>
> Is there a way I can build lift from the command line, using simple
> invocations of scalac only?
> I don't mind to do it bit by bit. I could isolate the previous fault
> myself, but for this one it looks like I need help because the file
> causing the crash depends on too many other things.
>
>  -- Martin
>



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

[Lift] Re: Catch file upload exceptions?

[Marius]

Catching OutOfMemory won't do you much good. You're already in an
inconsistent state and at that point your app should be restarted. Yes
LiftRules.exceptionHandler won't get you back in your upload work
flow. It is a mean for graceful degradation when unrecoverable errors
occur. Thus you can redirect to error pages, returning Ajax responses
in case the exception was thrown from an Ajax function etc.

Br's,
Marius

On Dec 22, 10:28 am, tiro  wrote:
> Well LiftRules.exceptionHandler was new to me so thanks. Great way to
> deal with the really unexpected (like OutOfMemory). Would do in the
> short run.
> However, the other Tim is correct in that I (and probably other
> people) really want to handle this like similarly to a validation
> error on any other field. LiftRules.exceptionHandler catches so far
> outside, as far as I understand, that the only way to get back into
> the workflow would be to kindly ask the user to press the Back button.

--

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: Catch file upload exceptions?

[Timothy Perrett]

Yes, your pretty much right.

Can you post your code thus far? (or a cut down version). If you box
the upload holder you should be ok (I think)

private object theUpload extends RequestVar[Box[FileParamHolder]]
(Empty)
SHtml.fileUpload(ul => theUpload(tryo(ul)))

That is, if your upload fails, tryo will stuff it into a Failure
instance.

Thoughts?

Cheers, Tim

On Dec 22, 8:28 am, tiro  wrote:
> Well LiftRules.exceptionHandler was new to me so thanks. Great way to
> deal with the really unexpected (like OutOfMemory). Would do in the
> short run.
> However, the other Tim is correct in that I (and probably other
> people) really want to handle this like similarly to a validation
> error on any other field. LiftRules.exceptionHandler catches so far
> outside, as far as I understand, that the only way to get back into
> the workflow would be to kindly ask the user to press the Back button.

--

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 could i send a HTTP get or post request in the Snippet or Views in the Lift?

[Neil.Lv]

  Ok, Thanks guys!

  I'll be try it .

Cheers.
  Neil

On Dec 22, 4:36 pm, Timothy Perrett  wrote:
> You might want to checkout the scala http library, dispatch:
>
> http://databinder.net/dispatch/
>
> Cheers, Tim
>
> On Dec 22, 7:46 am, Marius  wrote:
>
> > Well from your Snippet method you can just use HttpURLConnection, or
> > Apache Commons Client to make remote requests to other services. Of
> > course typically you won't do this directly from the snippet method
> > but from a Service layer of your application. One you get the response
> > (say it's an XML) you parse it using Scala XML class and the extract
> > relevant information using pattern matching or by some other means.
> > From here you just construct the NodeSeq that the Snippet/View needs
> > to return.
>
> > As a side note ...
> > If those requests are taking a long time, you can wrap your snippet in
> >  ... and it will be loaded asynchronously. There is
> > another attribute (lift:parallel="true")that you could specify to a
> > snippet that it will be run asynchronously allowing other snippets to
> > process and the result will be merged into the HTTP response right
> > before sending the response to the client. Note that you need to set
> > LiftRules.allowParallelSnippets
>
> > Br's,
> > Marius
>
> > On Dec 22, 8:39 am, "Neil.Lv"  wrote:
>
> > > Hi all,
>
> > >How could i send a HTTP get or post request in the Snippet or Views
> > > in the Lift?
>
> > >For example, the weather API .
>
> > > I want to send an HTTP get request or post request to another
> > > website that it supplies some
> > > APIs, then in the lift we can receive the return data such as XML
> > > data, so we can use these XML or Json data
> > > in the Snippet or the Views.
>
> > > Thanks for any help!
>
> > > 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] Re: PayPal X

[Timothy Perrett]

Doh! Thats not very helpful - CXF depends on JAX-WS, so same problems there. 
Looks like Apache Axis is AP2 licensed, but I really dont like Axis at all. Any 
ideas?

Cheers, Tim

On 22 Dec 2009, at 01:04, Ross Mellgren wrote:

> Looks like JAX-WS reference implementation is dual licensed CDDL or GPLv2.
> 
> -Ross
> 
> On Dec 21, 2009, at 7:32 PM, David Pollak wrote:
> 
>> 
>> 
>> On Mon, Dec 21, 2009 at 4:28 PM, Timothy Perrett  
>> wrote:
>> Cool - I'll have a play overthe hols.
>> 
>> It's a SOAP api so I'd need to depend on CXF or JAXWS... Do you forsee
>> any license conflicts before I start work?
>> 
>> As long as those libraries are Apache 2 or MIT/BSD licenses, all is good.
>>  
>> 
>> Cheers, Tim
>> 
>> On Dec 21, 6:58 pm, David Pollak 
>> wrote:
>> > On Sun, Dec 20, 2009 at 2:42 PM, Timothy Perrett 
>> > wrote:
>> >
>> > > 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.
>> >
>> > I'd love to see you write this Tim. ;-)
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > > 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.
>> >
>> > --
>> > Lift, the simply functional web frameworkhttp://liftweb.net
>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>> > Follow me:http://twitter.com/dpp
>> > Surf the harmonics
>> 
>> --
>> 
>> You received this message because you are subscribed to the Google Groups 
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/liftweb?hl=en.
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Lift, the simply functional web framework http://liftweb.net
>> Beginning Scala http://www.apress.com/book/view/1430219890
>> Follow me: http://twitter.com/dpp
>> Surf the harmonics
>> 
>> --
>> 
>> You received this message because you are subscribed to the Google Groups 
>> "Lift" group.
>> To post to this group, send email to lift...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> liftweb+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/liftweb?hl=en.
> 
> 
> --
> 
> 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: How could i send a HTTP get or post request in the Snippet or Views in the Lift?

[Timothy Perrett]

You might want to checkout the scala http library, dispatch:

http://databinder.net/dispatch/

Cheers, Tim

On Dec 22, 7:46 am, Marius  wrote:
> Well from your Snippet method you can just use HttpURLConnection, or
> Apache Commons Client to make remote requests to other services. Of
> course typically you won't do this directly from the snippet method
> but from a Service layer of your application. One you get the response
> (say it's an XML) you parse it using Scala XML class and the extract
> relevant information using pattern matching or by some other means.
> From here you just construct the NodeSeq that the Snippet/View needs
> to return.
>
> As a side note ...
> If those requests are taking a long time, you can wrap your snippet in
>  ... and it will be loaded asynchronously. There is
> another attribute (lift:parallel="true")that you could specify to a
> snippet that it will be run asynchronously allowing other snippets to
> process and the result will be merged into the HTTP response right
> before sending the response to the client. Note that you need to set
> LiftRules.allowParallelSnippets
>
> Br's,
> Marius
>
> On Dec 22, 8:39 am, "Neil.Lv"  wrote:
>
>
>
> > Hi all,
>
> >    How could i send a HTTP get or post request in the Snippet or Views
> > in the Lift?
>
> >    For example, the weather API .
>
> >     I want to send an HTTP get request or post request to another
> > website that it supplies some
> > APIs, then in the lift we can receive the return data such as XML
> > data, so we can use these XML or Json data
> > in the Snippet or the Views.
>
> >     Thanks for any help!
>
> > 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: Catch file upload exceptions?

[tiro]

Well LiftRules.exceptionHandler was new to me so thanks. Great way to
deal with the really unexpected (like OutOfMemory). Would do in the
short run.
However, the other Tim is correct in that I (and probably other
people) really want to handle this like similarly to a validation
error on any other field. LiftRules.exceptionHandler catches so far
outside, as far as I understand, that the only way to get back into
the workflow would be to kindly ask the user to press the Back button.

--

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.