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

2009-12-22 Thread 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 martin.oder...@epfl.chwrote:

 On Tue, Dec 22, 2009 at 11:11 AM, Heiko Seeberger
 heiko.seeber...@googlemail.com wrote:
  2009/12/22 martin odersky martin.oder...@epfl.ch
 
  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: [scala-internals] RC5 candidate for the first 2.8.0 beta

2009-12-22 Thread 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 feeder.of.the.be...@gmail.com
 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 martin.oder...@epfl.chwrote:

 On Tue, Dec 22, 2009 at 11:11 AM, Heiko Seeberger
 heiko.seeber...@googlemail.com wrote:
  2009/12/22 martin odersky martin.oder...@epfl.ch
 
  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: [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 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 martin.oder...@epfl.chwrote:

 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 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 joshua.suer...@gmail.com

 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 martin.oder...@epfl.chwrote:

 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





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

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.




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

2009-12-22 Thread 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 martin.oder...@epfl.chwrote:

 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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.




--

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




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

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

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

2009-12-22 Thread Kevin Wright
2009/12/22 David Bernard david.bernard...@gmail.com

 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 martin.oder...@epfl.chwrote:

 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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.



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




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

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 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
kev.lee.wri...@googlemail.comwrote:



 2009/12/22 David Bernard david.bernard...@gmail.com

 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 martin.oder...@epfl.chwrote:

 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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.



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




 --
 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.comliftweb%2bunsubscr...@googlegroups.com
 .
 For more options, visit this group at
 http://groups.google.com/group/liftweb?hl=en.


--

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




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

2009-12-22 Thread 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 martin.oder...@epfl.chwrote:

 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




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

2009-12-22 Thread 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: pathelement location=./scala-library-xyz.jar/

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 martin.oder...@epfl.ch
 mailto:martin.oder...@epfl.ch


 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 http://weiglewilczek.com
 My blog: heikoseeberger.name http://heikoseeberger.name
 Follow me: twitter.com/hseeberger http://twitter.com/hseeberger
 OSGi on Scala: scalamodules.org http://scalamodules.org
 Lift, the simply functional web framework: liftweb.net http://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.




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

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

 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: [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 Indrajit Raychaudhuri
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.

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 
 

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

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

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

--

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 Indrajit Raychaudhuri


On 22/12/09 11:06 PM, martin odersky 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.comwrote:

 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!

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

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

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

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

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.