Re: [Lift] Customizing meta fields

2010-03-08 Thread Martin Dale Lyness
Again, thank you so much for the help! The head merge feature is perfect for
this situation i described and my next line of though is right inline with
how you describe bind points!

Thanks again!

-- Martin

On Mon, Mar 8, 2010 at 12:47 PM, Ross Mellgren dri...@gmail.com wrote:

 For your particular example, you can use head merge as Naftoli suggests.
 Head merge is a behavior of Lift templates where any head tags will be
 merged together for the final output, so you put your meta
 name=description in each of the specific places, any general head stuff
 you want in your surrounding template and they will magically get folded
 together at render time.

 For other cases, you have a couple tools at your disposal:
  - RequestVars -- variables that are local to a particular page request.
 You can use these inside snippets to capture and recover values during
 template processing.
  - Bind points. In a surrounding template you can use tags like lift:bind
 name=foobar / and then define what to put there in the surrounded
 template using lift:bind-at name=foobarthe content/lift:bind-at

 And there are more. Hopefully head merging will work for you in this case.

 -Ross

 On Mar 7, 2010, at 8:25 PM, Martin Dale Lyness wrote:

 Thank you Ross, for the very informative response!

 Now, I consider SEO to be closer to a designer task than a developer task
 so keeping the power in the design documents would be my best idea. Is there
 anyway to allow individual pages to define blocks that are read into the
 snippets and then injected into the template?

 Here is the scenario i'm thinking of:
 1. A single uniform website template: default.html
 2. Several HTML files: index.html, product_list.html, product_overview.html
 3. Each of these HTML files containing lift:xxx tags referencing
 snippets.

 What i would want is for index.html, product_list.html, and
 product_overview.html to all use default.html and various Snippet classes.
 Now for SEO i would want the meta tags in the header of default.html to be
 customized to index.html, product_list.html, and product_overview.html;
 furthermore, product_list and product_overview are dynamic pages so they
 would need further customization based on what the snippets are returning.

 Essentially, i would want tags something like:
 lift:meta_descThis site is totally awesome, better than all our
 competitors/lift:meta_desc   in index.html
 lift:meta_descLook at all these products in
 %%category_name%%/lift:meta_descin product_list.html
 lift:meta_desc%product_name% - %product_description%/lift:meta_desc
 in product_overview.html

 The conceptual road block for me is coming from the controller first
 pattern used in frameworks like Rails. In lift snippets are not really the
 same conceptually. If i use the second proposed method
 (i.e. lift:HelloWorld.hello wrapping the entire template) i would have a
 battle between snippets used by each page. For example, perhaps i have a
 product overview snippet that sets the meta one way and a login snippet that
 sets it another way (intended for when show standalone in a login.html).

 The first solution with using a lift:HelloWorld.funcName / to inject a
 snippet at a meta location fits better because it would allow me to create a
 generic function that would attempt to create the keyword and description
 data based on whatever global information is made available to snippets by
 lift (i.e. Request Parameters?). My only problem with using this option is
 it puts all of the text on the developer side forcing the dev team to update
 descriptions and keywords where really the designers should be doing this.

 Does anyone have a suggestion on how to put the power in the hands of the
 designers in this type of situation?

 -- Martin

 On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren dri...@gmail.com wrote:

 To be parsed by the bind, it must be enclosed by
 lift:HelloWorld.hello.../lift:HelloWorld.hello

 There is relatively little magic -- Lift goes through your template
 looking for lift: prefixed tags. For those tags, it will look up a snippet
 class by using the part before the period (HelloWorld, in the above example)
 and then look for a method on that snippet class mentioned after the period
 (hello in the example). If there is no period, the method is assumed to be
 called render.

 Once that method is found, the method is called with the contents of the
 lift: tag, and the result of the method call is spliced into the XML to
 replace the lift: tag.

 bind is a function that does something kind of similar to overall template
 processing, except you supply some prefix other than lift: (b: in the
 example) and a limited set of things after the colon that are valid (time
 and meta_desc in the example)

 So, you might want something like this instead:

 meta name=descriptionlift:HelloWorld.meta_desc //meta

 class HelloWorld {

def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)

 }

 Which

[Lift] Customizing meta fields

2010-03-07 Thread Martin
How would one go about having dynamic description and keyword meta
tags in a template? Here is what i've tried:

default.html
meta name=descriptionb:meta_desc //meta

HelloWorld.scala
Helpers.bind(b, in, time - date.map(d = Text(d.toString)),
meta_desc - test desc)

I'm using a basic archetype build of 2.0-M3 and it produces an error:

This page contains the following errors:

error on line 6 at column 28: Namespace prefix b on meta_desc is not
defined
Below is a rendering of the page up to the first error.


It appears to me that the template is not parsed by the Helpers.bind,
is this correct?

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

2010-03-07 Thread Martin
Hey,

First of all, let me take the complete opposite stance observed from
one of the most reason posts from a Rails Junkie. I'm very excited
to see a framework that takes the good from so many different projects
and houses it under a language that does the same. I find it
refreshing to have the powerful tools developed around Java available
for development in this new Scala language and the Lift framework. No
matter how much one hates the design choices and the verbosity of the
most popular platform in our lifetime, it is only a benefit that we
have access to the years of effort devoted to it. The powerful
compiler behind Scala is my sole reason for preferring it to ports
like JRuby and Groovy.

Now to the point of my query, what is the activity and excitement
levels around lift at this point? I understand that money drives the
world and to make a framework successful one must market like Rails
and make some bank to promote future maintenance and improvements.

I notice the last production quality release was over a year ago; I do
notice there have been much more frequent updates to say the wiki and
the work on the 1.1 milestones. It just seems strange that a minor
release on such a young project would taking such a long time. This is
a completely naive view of what is going on, and this is why i post
this query because I want to be disproven so I can feel comfortable
suggesting the use of this framework for the long term.

Thanks for letting me take some of your time away from more important
things :). I just figured seeing this was a question in my mind,
others thinking about using the framework might have the same
question.

-- 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] Customizing meta fields

2010-03-07 Thread Martin Dale Lyness
Thank you Ross, for the very informative response!

Now, I consider SEO to be closer to a designer task than a developer task so
keeping the power in the design documents would be my best idea. Is there
anyway to allow individual pages to define blocks that are read into the
snippets and then injected into the template?

Here is the scenario i'm thinking of:
1. A single uniform website template: default.html
2. Several HTML files: index.html, product_list.html, product_overview.html
3. Each of these HTML files containing lift:xxx tags referencing snippets.

What i would want is for index.html, product_list.html, and
product_overview.html to all use default.html and various Snippet classes.
Now for SEO i would want the meta tags in the header of default.html to be
customized to index.html, product_list.html, and product_overview.html;
furthermore, product_list and product_overview are dynamic pages so they
would need further customization based on what the snippets are returning.

Essentially, i would want tags something like:
lift:meta_descThis site is totally awesome, better than all our
competitors/lift:meta_desc   in index.html
lift:meta_descLook at all these products in
%%category_name%%/lift:meta_descin product_list.html
lift:meta_desc%product_name% - %product_description%/lift:meta_desc
in product_overview.html

The conceptual road block for me is coming from the controller first pattern
used in frameworks like Rails. In lift snippets are not really the same
conceptually. If i use the second proposed method
(i.e. lift:HelloWorld.hello wrapping the entire template) i would have a
battle between snippets used by each page. For example, perhaps i have a
product overview snippet that sets the meta one way and a login snippet that
sets it another way (intended for when show standalone in a login.html).

The first solution with using a lift:HelloWorld.funcName / to inject a
snippet at a meta location fits better because it would allow me to create a
generic function that would attempt to create the keyword and description
data based on whatever global information is made available to snippets by
lift (i.e. Request Parameters?). My only problem with using this option is
it puts all of the text on the developer side forcing the dev team to update
descriptions and keywords where really the designers should be doing this.

Does anyone have a suggestion on how to put the power in the hands of the
designers in this type of situation?

-- Martin

On Sun, Mar 7, 2010 at 6:17 PM, Ross Mellgren dri...@gmail.com wrote:

 To be parsed by the bind, it must be enclosed by
 lift:HelloWorld.hello.../lift:HelloWorld.hello

 There is relatively little magic -- Lift goes through your template looking
 for lift: prefixed tags. For those tags, it will look up a snippet class by
 using the part before the period (HelloWorld, in the above example) and then
 look for a method on that snippet class mentioned after the period (hello in
 the example). If there is no period, the method is assumed to be called
 render.

 Once that method is found, the method is called with the contents of the
 lift: tag, and the result of the method call is spliced into the XML to
 replace the lift: tag.

 bind is a function that does something kind of similar to overall template
 processing, except you supply some prefix other than lift: (b: in the
 example) and a limited set of things after the colon that are valid (time
 and meta_desc in the example)

 So, you might want something like this instead:

 meta name=descriptionlift:HelloWorld.meta_desc //meta

 class HelloWorld {

def meta_desc(ns: NodeSeq): NodeSeq = Text(test desc)

 }

 Which will result in this XHTML:

 meta name=descriptiontest desc/meta

 Or, if you want to keep it in the hello method, you'd then have to move the
 lift:HelloWorld.hello to the outside of the template:

 lift:HelloWorld.hello
   ...
   head
 meta name=descriptionb:meta:desc //meta
 /head
...
b:time /
 /lift:HelloWorld.hello

 Hope that helps,
 -Ross


 On Mar 7, 2010, at 4:38 AM, Martin wrote:

  How would one go about having dynamic description and keyword meta
  tags in a template? Here is what i've tried:
 
  default.html
  meta name=descriptionb:meta_desc //meta
 
  HelloWorld.scala
  Helpers.bind(b, in, time - date.map(d = Text(d.toString)),
  meta_desc - test desc)
 
  I'm using a basic archetype build of 2.0-M3 and it produces an error:
 
  This page contains the following errors:
 
  error on line 6 at column 28: Namespace prefix b on meta_desc is not
  defined
  Below is a rendering of the page up to the first error.
 
 
  It appears to me that the template is not parsed by the Helpers.bind,
  is this correct?
 
  --
  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

[Lift] reload application.properties

2010-03-01 Thread Martin
Hi

is there any way to reload application.properties file after
boot.scala finishes? I would like to do dynamic localization of
properties on my site, without need to stop/start application.
Mayby there is  much better way to accomplish it.
I would really appreciate any help.

best regards,
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] anybody used OPA?

2010-02-23 Thread Martin Ellis
On 22 February 2010 21:45, Raoul Duke rao...@gmail.com wrote:
 This is related to Lift how? It appears to be a framework itself...

 i figure people who use Lift are the kinds of people who might have
 their ear to the ground for other approaches to the web problem, and
 might have insight into Competitor X, Y, or Z. i've certainly seen
 people talk about other Java solutions before, admittedly ML is
 further afield, although given Scala, not that much.

I must admit, my initial interest in Scala came from prior use of ML.

I can't answer your question, I'm afraid, but can offer some other
links you might find interesting if you haven't seen them already:

Ur/Web - web application language/framework.
http://impredicative.com/ur/

Yeti - ML-like language on the JVM.
http://wiki.github.com/mth/yeti/

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] OSGi example, what to do to make it run?

2010-02-05 Thread Martin Ellis
On 5 February 2010 05:00, philip philip14...@gmail.com wrote:
 I downloaded the git source and made a OSGi jar package by running the
 maven, now what do I do with it?

 I see its a jar file with the manifest for OSGi, I guess I can load it
 into Apache Felix, but doesn't Liftweb need tomcat or jetty to run? So
 I don't really understand how its going to run.

I've also puzzled over this.  I've figured out that you can point
pax-runner at the hello.composite file.

I'd love to see a tutorial on how experienced OSGI developers set up
their the development environment, and how they work the
edit/compile/redeploy cycle.  It's very obvious for mvn jetty:run
(just wait for the scanner, or use JavaRebel).  It's not so obvious
how people work with OSGI containers.  The best I've figured is to use
the pax assembly: stuff to point at target classes, and run update
bundle-id for each edit/compile cycle - it's a bit clunky.

Any offers/suggestions?  (Sorry, I realise the question more about
OSGI than lift)

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

2010-01-21 Thread martin odersky
(Un)fortunately I have an idea what the problem is. It's probably my
fix for #2867. I have now rolled back that fix in r20629. Can you
check again whether it works with that revision (should be in the
nightly tomorrow)? If it does we might be able to make an exception to
our RC = final rule, because this one just rolls back a non-critical
patch, so I fail to see how this could affect anything but the
original ticket.

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

2010-01-21 Thread martin odersky
On Thu, Jan 21, 2010 at 8:31 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 I've written a work-around and am currently testing the code more in a
 few minutes.

If you can make it work, so much the better. To give some info: The
original ticket had a vararg parameter of the form List[_]* in a case
class. This caused type inference for the synthetic equals method
(which uses sameElements for varargs) to fail, because the existential
in List[_] made the problem underconstrained. The patch passed the
argument type explicitly as the type parameter. In the lift case, it
seems that this explicit type parameter violated some type bound, so
the type inferencer should have chosen a more general type which would
not violate the bound. The easiest fix is probably to just roll back
and leave ticket #2867 open until we find a better solution. That's
what I have done.

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

2010-01-21 Thread martin odersky
On Thu, Jan 21, 2010 at 8:37 PM, David Pollak
feeder.of.the.be...@gmail.com wrote:
 Okay... the work-around is checked into the Lift repo.

 I say, Ship RC8 as the beta and we'll work through this (and likely other)
 issues during the beta period.

Sounds good. Thanks! -- Martin

 On Thu, Jan 21, 2010 at 11:36 AM, martin odersky martin.oder...@epfl.ch
 wrote:

 On Thu, Jan 21, 2010 at 8:31 PM, David Pollak
 feeder.of.the.be...@gmail.com wrote:
  I've written a work-around and am currently testing the code more in
  a
  few minutes.
 
 If you can make it work, so much the better. To give some info: The
 original ticket had a vararg parameter of the form List[_]* in a case
 class. This caused type inference for the synthetic equals method
 (which uses sameElements for varargs) to fail, because the existential
 in List[_] made the problem underconstrained. The patch passed the
 argument type explicitly as the type parameter. In the lift case, it
 seems that this explicit type parameter violated some type bound, so
 the type inferencer should have chosen a more general type which would
 not violate the bound. The easiest fix is probably to just roll back
 and leave ticket #2867 open until we find a better solution. That's
 what I have done.

 Cheers

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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth joshua.suer...@gmail.com 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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth joshua.suer...@gmail.com 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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 3:41 PM, Heiko Seeberger
heiko.seeber...@googlemail.com 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
 PATH-TO-SCALAC-OR-FSC-2.8-BETA1-RC5 -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

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

2009-12-22 Thread 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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
indraj...@gmail.com wrote:
 Martin,

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

 It should be:

        groupIdorg.mortbay.jetty/groupId
        artifactIdjetty/artifactId
        version[6.1.6,7.0)/version

 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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
indraj...@gmail.com wrote:
 Martin,

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

 It should be:

        groupIdorg.mortbay.jetty/groupId
        artifactIdjetty/artifactId
        version[6.1.6,7.0)/version

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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
indraj...@gmail.com wrote:

 On 22/12/09 10:44 PM, martin odersky wrote:

 On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
 indraj...@gmail.com  wrote:

 Martin,

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

 It should be:

        groupIdorg.mortbay.jetty/groupId
        artifactIdjetty/artifactId
        version[6.1.6,7.0)/version

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

  modules
    modulelift-base/module
    modulelift-persistence/module
    modulelift-modules/module
    !--modulelift-archetypes/module--
    !--modulelift-examples/module--

    !-- the 'meta' module --
    !--modulelift-core/module--
  /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

2009-12-22 Thread 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 martin.oder...@epfl.ch wrote:
 On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri
 indraj...@gmail.com wrote:

 On 22/12/09 10:44 PM, martin odersky wrote:

 On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri
 indraj...@gmail.com  wrote:

 Martin,

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

 It should be:

        groupIdorg.mortbay.jetty/groupId
        artifactIdjetty/artifactId
        version[6.1.6,7.0)/version

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

  modules
    modulelift-base/module
    modulelift-persistence/module
    modulelift-modules/module
    !--modulelift-archetypes/module--
    !--modulelift-examples/module--

    !-- the 'meta' module --
    !--modulelift-core/module--
  /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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 6:48 PM, martin odersky martin.oder...@epfl.ch 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

2009-12-22 Thread martin odersky
On Tue, Dec 22, 2009 at 7:12 PM, Paul Phillips pa...@improving.org 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:

 -    scala.version2.8.0.Beta1-RC3/scala.version
 +    scala.version2.8.0.Beta1-RC5/scala.version

 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.




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

2009-12-21 Thread martin odersky
On Sun, Dec 20, 2009 at 12:39 PM, martin odersky martin.oder...@epfl.ch wrote:
 Thanks for letting us know. This looks like something stirred up by
 the change in erasure. We'll investigate Monday what it is.

 Cheers

  -- Martin

I could reproduce the fault and think I found the underlying problem:
There was a problem with the erasure of self types  and it looks like
this problem was unmasked by my previous, unrelated change to erasure.
I'll think about a fix now.

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

2009-12-20 Thread martin odersky
Thanks for letting us know. This looks like something stirred up by
the change in erasure. We'll investigate Monday what it is.

Cheers

 -- Martin

On Sun, Dec 20, 2009 at 11:43 AM, Heiko Seeberger
heiko.seeber...@googlemail.com wrote:
 Lift built against RC3, but with RC4 we get this error:
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.scala_tools.maven.executions.MainHelper.runMain(MainHelper.java:151)
 at
 org.scala_tools.maven.executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26)
 Caused by: java.lang.AssertionError: assertion failed: type error: can't
 convert from REFERENCE(net.liftweb.util.StringHelpers) to
 REFERENCE(net.liftweb.util.BasicTypesHelpers) in unit
 BasicTypesHelpers.scala
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:943)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:927)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadLabelArguments(GenICode.scala:990)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:710)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadIf(GenICode.scala:363)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:511)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:484)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:850)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:130)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
 at scala.collection.immutable.List.foreach(List.scala:46)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:152)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:106)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
 at scala.collection.immutable.List.foreach(List.scala:46)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87)
 at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97)
 at scala.collection.immutable.List.foreach(List.scala:46)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:83)
 at
 scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:79)
 at
 scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281)
 at
 scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281)
 at scala.tools.nsc.reporters.Reporter.withSource(Reporter.scala:48)
 at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:281)
 at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259)
 at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259)
 at scala.collection.Iterator$class.foreach(Iterator.scala:582)
 at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:285)
 at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:259)
 at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:72)
 at scala.tools.nsc.Global$Run.compileSources(Global.scala:749)
 at scala.tools.nsc.Global$Run.compile(Global.scala:839)
 at scala.tools.nsc.Main$.process(Main.scala:109)
 at scala.tools.nsc.Main$.main(Main.scala:123)
 at scala.tools.nsc.Main.main(Main.scala)
 ... 6 more
 Heiko
 My job: weiglewilczek.com
 My blog: heikoseeberger.name
 Follow me

[Lift] Problems downloading dependencies, can't get started

2009-11-14 Thread Nate Martin

Hi-

I was very intrigued with Lift, so I tried to work my way through the
Hello World tutorial. Unfortunately, I can't seem to get that to work.

I'm running on Snow Leopard. I installed Lift with the installer
downloaded from the Lift web site (version 1.0.1). When I first ran
mvn jetty:run it tried to download a bunch of dependencies.
Unfortunately, I was in china on a business trip when this happened,
and because of my spotty internet connection, I don't think all the
dependencies downloaded, and I couldn't launch the hello world
tutorial.

Now, I'm back in the states, but I can't figure out how to get Maven
to retry downloading the dependencies. All that happens when I type
mvn jetty:run is:

[INFO] Copying 0 resource
[WARNING] POM for 'backport-util-concurrent:backport-util-
concurrent:pom:3.0:runtime' is invalid.

Its dependencies (if any) will NOT be available to the current build.
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error configuring: net.sf.alchim:yuicompressor-maven-plugin.
Reason: A required class was missing during mojo configuration: org/
mozilla/javascript/ErrorReporter
[INFO]

[INFO] For more information, run Maven with the -e switch


Can anyone give me some advice on fixing this?

Thanks,
Nate

--~--~-~--~~~---~--~~
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] Re: Problems downloading dependencies, can't get started

2009-11-14 Thread Nate Martin

Fantastic, that worked great!

Mentioning this tip in the tutorial might be a good idea.

Thanks!

On Nov 14, 4:37 pm, Jim Barrows jim.barr...@gmail.com wrote:
 Nate there is a directory in your home directory called .m2.  Delete that 
 and retry.
 If that doesn't work, and nobody else jumps in, its an issue with maven.  I'm 
 mobile abd be more helpful I'm afraid.
 Sent on the Now Network™ from my Sprint® BlackBerry



 -Original Message-
 From: Nate Martin natmar...@gmail.com
 Date: Sat, 14 Nov 2009 16:32:19
 To: Liftliftweb@googlegroups.com
 Subject: [Lift] Problems downloading dependencies, can't get started

 Hi-

 I was very intrigued with Lift, so I tried to work my way through the
 Hello World tutorial. Unfortunately, I can't seem to get that to work.

 I'm running on Snow Leopard. I installed Lift with the installer
 downloaded from the Lift web site (version 1.0.1). When I first ran
 mvn jetty:run it tried to download a bunch of dependencies.
 Unfortunately, I was in china on a business trip when this happened,
 and because of my spotty internet connection, I don't think all the
 dependencies downloaded, and I couldn't launch the hello world
 tutorial.

 Now, I'm back in the states, but I can't figure out how to get Maven
 to retry downloading the dependencies. All that happens when I type
 mvn jetty:run is:

 [INFO] Copying 0 resource
 [WARNING] POM for 'backport-util-concurrent:backport-util-
 concurrent:pom:3.0:runtime' is invalid.

 Its dependencies (if any) will NOT be available to the current build.
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Error configuring: net.sf.alchim:yuicompressor-maven-plugin.
 Reason: A required class was missing during mojo configuration: org/
 mozilla/javascript/ErrorReporter
 [INFO]
 
 [INFO] For more information, run Maven with the -e switch

 Can anyone give me some advice on fixing this?

 Thanks,
 Nate

--~--~-~--~~~---~--~~
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] Re: Removing Scala Actors from Lift

2009-10-02 Thread martin

Hi Jonas,

On Sep 30, 8:05 pm, Jonas Bonér jbo...@gmail.com wrote:
 Hi Martin and Philipp.

 Thanks for your email. What you are saying sounds great. I love Scala
 Actors and I know its an important thing that brings people over to
 Scala.

 I hope that I didn't offend you. You have done amazing things with and
 for Scala. I really respect you guys.

 But I saw and felt the need for something like Akka and went away and build 
 it.

I think you have done a great thing with Akka, and I'm very glad you
did it! That's precisely the strength of Scala that experts can build
great libraries and high-level domain specific languages on it. I
really like where you are taking Akka, and I hope it will be very
succesfull.

As I wrote before, we are not at all defensive about our own actor
library. I think Scala actors are very useful for lots of people who
need easy and performant support for concurrent programs. If you need
to take it further (such as remoting, supervising, persistence), there
might be other more complete systems like Akka that can pick up there
and provide these things. We at EPFL simply do not have the
contributor base to do that ourselves, and that's also not our
mission, I think. We need to concentrate on core language, tools, and
some core libraries (if there's nobody else doing those). So I see
Akka as a very important upgrade path from simple multicore
concurrency to robust distributed systems. And I hope that other
people will do the same in other areas, such as I/O, serialization,
graphics, and so on.
If we can collaborate on those, great, but if people find it easier to
do their own thing, that's also perfectly fine.

The only thing I am asking is to avoid confusion to outside people. Be
clear what role you API serves, how it is different from others. Avoid
using the same name for different things.

Cheers

 -- Martin
--~--~-~--~~~---~--~~
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] Re: Removing Scala Actors from Lift

2009-09-30 Thread martin

About actors in Scala 2.8:

 . they have been refactored substantially compared to what's in the
   2.7.x branch
 . Philipp has sent mails about this to scala-internals (05/31)
 . Philipp has invited DPP to look at the refactorings in 2.8 (07/21)
to which
   he responded positively.
 . The ForkJoinPool in 2.8 is completely different from FJTask in
   2.7.5; it's the version that's going into JDK7. It has been
   battle-tested and should not suffer from any memory leaks.

The reason why Scala actors use the FJ framework is performance, in
particular on multi-core hardware. So we do not think it's a good idea
to go back to java.util.concurrent, except maybe for applications with
very specialized demands.

We think the main problem was that lift depends on Scala 2.7.x, and
that the actor refactorings have not gone into the 2.7.x branch. The
result is that people have not noticed the changes. For example, most
of the issues that Erik raises in his blog post no longer apply to
Scala 2.8. Initially we wanted 2.8 to be out by now, but it's taken
much longer than we have foreseen, because some of the problems were
harder than initially thought. We are sorry to have left the 2.7
branch relatively unattended for so long. It's difficult for us,
though, to provide the resources to support two diverging branches in
parallel. More community support with backports etc could help.

To fix the concrete issue at hand, we replaced FJTask with (a backport
of) java.util.concurrent.ThreadPoolExecutor in the Scala 2.7.x branch,
to be released as 2.7.7. That takes care of the memory leaks in
FJTask.

Now to the larger picture. We are not at all wedded to Scala actors
here; after all it's just a library. If there are others which fulfill
some needs better, great! But we have to be honest to avoid confusion.
One of the main differences between Scala actors and lift actors and
Akka seems to be that only Scala actors provide nested receives, so
only Scala actors really let you avoid an inversion of control. This
is a feature which complicates the implementation considerably, and
that's what all our main results are about. You might not care about
this particular feature in your code, and consequently you might
choose a different abstraction. But calling that abstraction simply
`actors' causes unnecessary confusion, in our opinion. And that's not
good for the goal of convincing people that actors are a useful
concurrency abstraction. So, nothing against lift actors and Akka, but
we need to be precise about the tradeoffs. Maybe call them `flat
actors' or something like that.

Martin and Philipp

--~--~-~--~~~---~--~~
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] Re: automaticly generated forms and submit button naming

2009-09-28 Thread Martin

Hi,

Ross, thank you for your help. This code works perfectly for me. I
heaven't noticed I could group many elements in one lift tag.

I changed somethings in your code. Maybe it's not worth mentioning but
if someone has similar problems it can help a little.
I corrected only to things: changed parameters order in one bind and
added some code to other.
Result is here:

def newPlace(ns: NodeSeq, place : Place): NodeSeq = {
def bindFields(innerNs: NodeSeq): NodeSeq = {
var s : String = test
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
flatMap(f = {
f.toForm.toList.map(form = {
bind(field,
innerNs,
displayName -
 f.displayName,
form-
 form)(1);
})
})
}

def handleSubmit(): Any = {
}

bind(place, ns,
 fields - { (ns: NodeSeq) = bindFields(ns) },
 submit - { (ns: NodeSeq) = SHtml.submit(Submit new
place, handleSubmit _) })
}

Still I don't get why I need to get second element from bind result
(which is NodeSeq) and pass it to .toForm.toList.map(...).
When I first compiled this code i got type mismatch error:
 found   : scala.xml.NodeSeq
 required: scala.xml.Node

So I picked up first non empty element from the result by using bind
(...)(1) and it works in my scenario. Maybe I will catch it later ;)

Again this code works perfectly for me. Great thanks Ross!

- Martin




On 24 Wrz, 16:15, Ross Mellgren dri...@gmail.com wrote:
 It sounds like you probably want p{ SHtml.submit(Title of submit  
 button, () = actionToTakeWhenButtonIsUsedToSubmitForm) }/p

 By the way, what you have there doesn't seem to be following the usual  
 lift pattern of binding snippets, is there a reason that you prefer  
 this to:

 template:

 lift:MySnippet.newPlace form=post
      h4Place details/h4
      div
          place:fields
              p
                  labelfield:displayName //label
                  field:form /
              /p
          /place:fields
      /div
      pplace:submit //p
 /lift:MySnippet.newPlace

 Snippet:

 def newPlace(ns: NodeSeq): NodeSeq = {
      val place = /* make a new place somehow */

      def bindFields(ns: NodeSeq): NodeSeq =
          signupFields.
              map(fi = getSingleton.getActualBaseField(place, fi)).
              flatMap(f = {
                  f.toForm.toList.map(form = {
                      bind(ns, field,
                           displayName - f.displayName,
                           form        - form)
                  })
              })

      def handleSubmit(): Any = /* do something with place */

      bind(place, ns,
           fields - { (ns: NodeSeq) = bindFields(ns) },
           submit - { (ns: NodeSeq) = SHtml.submit(Submit new  
 Place, handleSubmit _) })

 }

 This way lets you see most of the HTML in one place (the template). I  
 inlined localForm, but there's no particular reason that it needs to  
 be local (other than it closes on place, but you could just pass that  
 in)

 -Ross

 On Sep 24, 2009, at 6:55 AM, Martin wrote:



  Hi all,

  I've got a following problem. When I create a form form automaticly..
  similar to the User login/register example I encontered a problem I'm
  not posible to cope with.

  Firstly I have 'written' a function (using CopyPaste method) which
  creates a form fields list based on my class properties:

     private def localForm(place: Place, ignorePassword: Boolean):
  NodeSeq = {
         signupFields.
         map(fi = getSingleton.getActualBaseField(place, fi)).
         filter(f = !ignorePassword || (f match {
                     case f: MappedPassword[Place] = false
                     case _ = true
                 })).
         flatMap(f =
             f.toForm.toList.map(form = plabel{f.displayName}/
  label {form}/p) )
     }

  Next, I wrote some code to return a complete form to the snippet:

     def newPlace(place: Place) =
     form method=post action={S.uri}
         h4Place details/h4
         div
             {
                 localForm(place, false)
             }
         /div
         p_WHAT_SHOULD_I_WRITE_HERE_:submit //p
     /form

  My question is... what do I write in _WHAT_SHOULD_I_WRITE_HERE_ ?
  Or better.. how/where to define this value?

  In a user login/register example there is submit defined like this:
  user:submit

  Placing there name of the owner class didn't work.
  I know I could use bind but as far as I know next I should create a
  complete snippet with all the fields by hand.. and I would to avoid
  it.

  I was digging for solution in a Lift Book and on group as well, but
  without success.
  Help!

--~--~-~--~~~---~--~~
You received

[Lift] automaticly generated forms and submit button naming

2009-09-24 Thread Martin

Hi all,

I've got a following problem. When I create a form form automaticly..
similar to the User login/register example I encontered a problem I'm
not posible to cope with.

Firstly I have 'written' a function (using CopyPaste method) which
creates a form fields list based on my class properties:

private def localForm(place: Place, ignorePassword: Boolean):
NodeSeq = {
signupFields.
map(fi = getSingleton.getActualBaseField(place, fi)).
filter(f = !ignorePassword || (f match {
case f: MappedPassword[Place] = false
case _ = true
})).
flatMap(f =
f.toForm.toList.map(form = plabel{f.displayName}/
label {form}/p) )
}

Next, I wrote some code to return a complete form to the snippet:


def newPlace(place: Place) =
form method=post action={S.uri}
h4Place details/h4
div
{
localForm(place, false)
}
/div
p_WHAT_SHOULD_I_WRITE_HERE_:submit //p
/form


My question is... what do I write in _WHAT_SHOULD_I_WRITE_HERE_ ?
Or better.. how/where to define this value?

In a user login/register example there is submit defined like this:
user:submit

Placing there name of the owner class didn't work.
I know I could use bind but as far as I know next I should create a
complete snippet with all the fields by hand.. and I would to avoid
it.

I was digging for solution in a Lift Book and on group as well, but
without success.
Help!

--~--~-~--~~~---~--~~
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] Re: problems logging

2009-05-19 Thread Martin Ellis

 On May 17, 10:33 pm, Timothy Perrett timo...@getintheloop.eu wrote:
 Can you verify the log4j.xml file is being read?


On Mon, May 18, 2009 at 9:38 PM, Channing Walton channingwal...@mac.com wrote:
 Not sure how I can tell.

Specifying -Dlog4j.debug on the command line should prompt log4j to tell you
what it's doing.

Martin

--~--~-~--~~~---~--~~
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] Why XML tags, not attributes, for lift markup?

2009-05-19 Thread Martin Ellis

Hi,

I was wondering why lift markup uses XML elements to reference
snippets, rather than using namespaced attributes in the way that (I
think) Wicket and Tapestry do?  Or like Plone's TAL, which is the
first place I saw such a thing.

The reason I ask is this: I'm sure I've read somewhere that David P
has used these frameworks before (the Java ones, at least)... so it
seems most unlikely that such a design was never considered.  Perhaps
it was just an arbitrary choice?  Or was there something more to it
than that?

I hope this question doesn't sound like criticism - I'm just curious. :o)

Martin

--~--~-~--~~~---~--~~
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] Re: Progress on JPADemo and JTA

2008-10-10 Thread Martin Ellis

On Fri, Oct 10, 2008 at 10:37 PM, Derek Chen-Becker
[EMAIL PROTECTED] wrote:
 OK, I think I know how to create a new branch, but being a Git newb I really
 don't want to nuke anything. Do I just do a git branch my new branch
 name in my local repo?

I think you want: git checkout -b branchName

git branch on it's own won't switch to the new branch.

Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: expired sessions and log in

2008-10-05 Thread Martin Ellis

On Sun, Oct 5, 2008 at 7:28 PM, Charles F. Munat [EMAIL PROTECTED] wrote:

 I'm working on an app in which users may spend significant time editing
 a form before submitting it. It's possible during this time that their
 session could time out. My concern is that they might submit a long
 edit, discover that their session has timed out, log in, and lose the
 edit. (They can probably back up and resubmit, but these are not very
 savvy users.)

 I'd like it to remember their update, hold it until they log back in,
 then send them a prompt to ask if they want to:

 a) complete the update,
 b) cancel the update,
 c) return to the edit form (with their recent edits included, though not
 yet saved).

 Any ideas for how to go about this?

I guess it's still true that:

  The best way to deal with the particular situation (browser
  open, don't want the session to disappear), is to put a hidden
  CometActor on the page that does nothing other than keep
  the session alive. - David Pollack
  
http://groups.google.com/group/liftweb/browse_thread/thread/e98f2f75cc4461e4/10a16b586e879b11


Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Caching JPA entities and JPA vs Hibernate

2008-10-01 Thread Martin Ellis

On Tue, Sep 30, 2008 at 11:54 PM, Tim Perrett [EMAIL PROTECTED] wrote:

 Having an issue with ehcache.xml being picked up. The docs say that it
 need to be on the classpath - I've tried having it in META-INF, WEB-
 INF/classes/META-INF but yet nothing seems to work. It never gets
 picked up...?

 Where can i stick it so that its forced to be read?

IIRC, it needs to be at the top of the classpath, not under META-INF.

Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---



[Lift] Re: Many to many in Lift mapper

2008-09-20 Thread Martin Ellis

On Sat, Sep 20, 2008 at 10:01 PM, Charles F. Munat [EMAIL PROTECTED] wrote:
 I can't find any examples of a many-to-many relationship using Lift's
 mapper. Am I missing one? How does one map two classes in a many-to-many
 bidirectional relationship?

Using the HasManyThrough class:

http://liftweb.net/index.php/HowTo_setup_composite_keys

Martin

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---