[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
I'm cc'ing this to the Lift list. Perhaps Indrajit or another Maven guru can help out. On Tue, Dec 22, 2009 at 2:32 AM, martin odersky wrote: > On Tue, Dec 22, 2009 at 11:11 AM, Heiko Seeberger > wrote: > > 2009/12/22 martin odersky > >> > >> Annoying... Just to explain what goes on here. Between RC3 and RC4 we > >> tightened the erasure of compund types > >> T with U where T and U are traits. These used to be all erased to > >> Object and now are erased to the first trait in the sequence, i.e. T > >> in the example above. Unfortunately it seems the previous behavior of > >> erasing to Object hid a few bugs in prior transformation phases where > >> one should have taken the self type of a class and one took instead > >> the type of the class itself. These bugs are now crawling out, and it > >> seems that lift is their primary crawling ground, probably because of > >> its ubiquitous pattern of using self types that are compound types of > >> traits. > > > > Making them creep out sooner than later is beneficial, even if it causes > > some pain right now ;-) > > > >> > >> Another problem is that lift by itself is hard to test for me because > >> it requires maven (and I am no maven expert) and maven requires a full > >> build, which takes time to do. So the turn around time is quite high, > >> many hours to days instead of minutes. Any ideas what one can do to > >> address these issues would be welcome. > > > > Meanwhile Lift is a large and highly modular framework. The RC4 error > > occurred while building lift-util which is a prerequisite module (built > in > > the very beginning). The RC5 error occurred while building lift-mapper, > > which is already outside of the lift-base modules. Hence I am optimistic > > that we do not need many further rounds. > > Heiko > > Is there a way I can build lift from the command line, using simple > invocations of scalac only? > I don't mind to do it bit by bit. I could isolate the previous fault > myself, but for this one it looks like I need help because the file > causing the crash depends on too many other things. > > -- Martin > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
I think staying in maven would require the least amount of typing, but the most amount of time as you'd have to publish local snapshots of Scala 2.8.0 to use them in the lift build. I remember how annoying this is ;). Also note that deploying maven requires a full scala build, but if needed I can make a short-cut that will just publish the "quick" libraries. This would help immensely in testing trunk against projects, but is not very helpful otherwise. Would this be desirable? What was already suggested (runing mvn dependency:copy-dependencies) is very viable. However, if lift-mapper relies on lift-util, you'll have to rebuild one before you rebuild the other if you're somehow changing the ABI. If you still wanted to use maven, I recommend using the reactor plugin. If you identify the project that is failing you can run: mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the failing module. This will only build the lift-mapper module and other modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util (and only lift-util) just those two will be built. I have a local VM where I was setting up a scala nightly build that would feed maven. Perhaps when I finish I'll make a write-up on how to do this, or have some kind of template/script you can use to do it by hand. - Josh On Tue, Dec 22, 2009 at 7:24 AM, David Pollak wrote: > I'm cc'ing this to the Lift list. Perhaps Indrajit or another Maven guru > can help out. > > > On Tue, Dec 22, 2009 at 2:32 AM, martin odersky wrote: > >> On Tue, Dec 22, 2009 at 11:11 AM, Heiko Seeberger >> wrote: >> > 2009/12/22 martin odersky >> >> >> >> Annoying... Just to explain what goes on here. Between RC3 and RC4 we >> >> tightened the erasure of compund types >> >> T with U where T and U are traits. These used to be all erased to >> >> Object and now are erased to the first trait in the sequence, i.e. T >> >> in the example above. Unfortunately it seems the previous behavior of >> >> erasing to Object hid a few bugs in prior transformation phases where >> >> one should have taken the self type of a class and one took instead >> >> the type of the class itself. These bugs are now crawling out, and it >> >> seems that lift is their primary crawling ground, probably because of >> >> its ubiquitous pattern of using self types that are compound types of >> >> traits. >> > >> > Making them creep out sooner than later is beneficial, even if it causes >> > some pain right now ;-) >> > >> >> >> >> Another problem is that lift by itself is hard to test for me because >> >> it requires maven (and I am no maven expert) and maven requires a full >> >> build, which takes time to do. So the turn around time is quite high, >> >> many hours to days instead of minutes. Any ideas what one can do to >> >> address these issues would be welcome. >> > >> > Meanwhile Lift is a large and highly modular framework. The RC4 error >> > occurred while building lift-util which is a prerequisite module (built >> in >> > the very beginning). The RC5 error occurred while building lift-mapper, >> > which is already outside of the lift-base modules. Hence I am optimistic >> > that we do not need many further rounds. >> > Heiko >> >> Is there a way I can build lift from the command line, using simple >> invocations of scalac only? >> I don't mind to do it bit by bit. I could isolate the previous fault >> myself, but for this one it looks like I need help because the file >> causing the crash depends on too many other things. >> >> -- Martin >> > > > > -- > Lift, the simply functional web framework http://liftweb.net > Beginning Scala http://www.apress.com/book/view/1430219890 > Follow me: http://twitter.com/dpp > Surf the harmonics > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth wrote: > I think staying in maven would require the least amount of typing, but the > most amount of time as you'd have to publish local snapshots of Scala 2.8.0 > to use them in the lift build. I remember how annoying this is ;). Also > note that deploying maven requires a full scala build, but if needed I can > make a short-cut that will just publish the "quick" libraries. This would > help immensely in testing trunk against projects, but is not very helpful > otherwise. Would this be desirable? > > What was already suggested (runing mvn dependency:copy-dependencies) is very > viable. However, if lift-mapper relies on lift-util, you'll have to > rebuild one before you rebuild the other if you're somehow changing the ABI. > > If you still wanted to use maven, I recommend using the reactor plugin. If > you identify the project that is failing you can run: > > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper > > Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the > failing module. This will only build the lift-mapper module and other > modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util > (and only lift-util) just those two will be built. > > I have a local VM where I was setting up a scala nightly build that would > feed maven. Perhaps when I finish I'll make a write-up on how to do this, > or have some kind of template/script you can use to do it by hand. > > - Josh > Hi Josh, The problem is not so much building individual maven modules, but building them with experimental compilers. I need to be able to put a println into scalac, rebuild that (takes 10sec with fsc) and then recompile the offending maven part with that compiler. That's why I need a version of lift that can be compiled without maven. It need not be perfect, for instance one can probably throw out all the tests. But I need to be able to use lift as a rapid experimentation tool for the scala compiler itself. Unfortunately, LAMP is pretty much shutting down for the holidays right now. So any outside help that you can give is appreciated. Ideally: I get the right lift version as a tarball, together with all jars that it needs. Then, instructions what to compile in what order (I can probably figure them out in a pinch, but if someone knows that already, it would help). Thanks -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
For curiousities sake, if you're building using fsc, are you running scalac via an exploded classpath (i.e. not a JAR file?). If so, I'll try to come up with a longer-term solution for this. If we allowed you to do the following: mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala -Dscala.local.classpath=classfiledir would that be sufficient? We could also have this do conditional computation in the future. - Josh On Tue, Dec 22, 2009 at 8:12 AM, martin odersky wrote: > On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth > wrote: > > I think staying in maven would require the least amount of typing, but > the > > most amount of time as you'd have to publish local snapshots of Scala > 2.8.0 > > to use them in the lift build. I remember how annoying this is ;). > Also > > note that deploying maven requires a full scala build, but if needed I > can > > make a short-cut that will just publish the "quick" libraries. This > would > > help immensely in testing trunk against projects, but is not very helpful > > otherwise. Would this be desirable? > > > > What was already suggested (runing mvn dependency:copy-dependencies) is > very > > viable. However, if lift-mapper relies on lift-util, you'll have to > > rebuild one before you rebuild the other if you're somehow changing the > ABI. > > > > If you still wanted to use maven, I recommend using the reactor plugin. > If > > you identify the project that is failing you can run: > > > > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper > > > > Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the > > failing module. This will only build the lift-mapper module and other > > modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util > > (and only lift-util) just those two will be built. > > > > I have a local VM where I was setting up a scala nightly build that would > > feed maven. Perhaps when I finish I'll make a write-up on how to do > this, > > or have some kind of template/script you can use to do it by hand. > > > > - Josh > > > Hi Josh, > > The problem is not so much building individual maven modules, but > building them with experimental compilers. I need to be able to put a > println into scalac, rebuild that (takes 10sec with fsc) and then > recompile the offending maven part with that compiler. That's why I > need a version of lift that can be compiled without maven. It need not > be perfect, for instance one can probably throw out all the tests. But > I need to be able to use lift as a rapid experimentation tool for the > scala compiler itself. > > Unfortunately, LAMP is pretty much shutting down for the holidays > right now. So any outside help that you can give is appreciated. > Ideally: I get the right lift version as a tarball, together with all > jars that it needs. Then, instructions what to compile in what order > (I can probably figure them out in a pinch, but if someone knows that > already, it would help). > > Thanks > > -- Martin > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Another possibility is to specify scala as a system dependency in Lift's pom: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies Then hard code the path that scalac's being built into. put maven in offline mode as well, and it should be nice and quick. 2009/12/22 Josh Suereth > For curiousities sake, if you're building using fsc, are you running scalac > via an exploded classpath (i.e. not a JAR file?). If so, I'll try to come > up with a longer-term solution for this. > > If we allowed you to do the following: > > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala > -Dscala.local.classpath=classfiledir > > would that be sufficient? We could also have this do conditional > computation in the future. > > - Josh > > > On Tue, Dec 22, 2009 at 8:12 AM, martin odersky wrote: > >> On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth >> wrote: >> > I think staying in maven would require the least amount of typing, but >> the >> > most amount of time as you'd have to publish local snapshots of Scala >> 2.8.0 >> > to use them in the lift build. I remember how annoying this is ;). >> Also >> > note that deploying maven requires a full scala build, but if needed I >> can >> > make a short-cut that will just publish the "quick" libraries. This >> would >> > help immensely in testing trunk against projects, but is not very >> helpful >> > otherwise. Would this be desirable? >> > >> > What was already suggested (runing mvn dependency:copy-dependencies) is >> very >> > viable. However, if lift-mapper relies on lift-util, you'll have to >> > rebuild one before you rebuild the other if you're somehow changing the >> ABI. >> > >> > If you still wanted to use maven, I recommend using the reactor >> plugin. If >> > you identify the project that is failing you can run: >> > >> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper >> > >> > Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the >> > failing module. This will only build the lift-mapper module and other >> > modules on which lift-mapper depends (i.e. if lift-mapper needs >> lift-util >> > (and only lift-util) just those two will be built. >> > >> > I have a local VM where I was setting up a scala nightly build that >> would >> > feed maven. Perhaps when I finish I'll make a write-up on how to do >> this, >> > or have some kind of template/script you can use to do it by hand. >> > >> > - Josh >> > >> Hi Josh, >> >> The problem is not so much building individual maven modules, but >> building them with experimental compilers. I need to be able to put a >> println into scalac, rebuild that (takes 10sec with fsc) and then >> recompile the offending maven part with that compiler. That's why I >> need a version of lift that can be compiled without maven. It need not >> be perfect, for instance one can probably throw out all the tests. But >> I need to be able to use lift as a rapid experimentation tool for the >> scala compiler itself. >> >> Unfortunately, LAMP is pretty much shutting down for the holidays >> right now. So any outside help that you can give is appreciated. >> Ideally: I get the right lift version as a tarball, together with all >> jars that it needs. Then, instructions what to compile in what order >> (I can probably figure them out in a pinch, but if someone knows that >> already, it would help). >> >> Thanks >> >> -- Martin >> > > -- Kevin Wright mail/google talk: kev.lee.wri...@googlemail.com wave: kev.lee.wri...@googlewave.com skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth wrote: > For curiousities sake, if you're building using fsc, are you running scalac > via an exploded classpath (i.e. not a JAR file?). If so, I'll try to come > up with a longer-term solution for this. Yes, exactly. My usual setup is that my output directory is the first item on the classpath. So any files I recompile get chosen first. > > If we allowed you to do the following: > > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala > -Dscala.local.classpath=classfiledir > > would that be sufficient? We could also have this do conditional > computation in the future. Does that mean that the scala compiler would then be run out of classfiledir? Yes, that could work. Cheers -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Martin, OK, now I got it working (almost) without Maven: 1. step: Check out 280_port branch from g...@github.com:dpp/liftweb.git 2. step: cd into liftweb/lift-persistence/lift-mapper and run mvn dependency:copy-dependencies 3. step: run the following command -classpath `find target/dependency -name *.jar | xargs scala -e 'println(args mkString ":")'` -sourcepath src/main/scala -d target/classes `find src/main/scala -name *.scala` This will only use Maven to download the dependencies, but you can compile with scalac or fsc. Heiko -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 3:41 PM, Heiko Seeberger wrote: > Martin, > OK, now I got it working (almost) without Maven: > 1. step: > Check out 280_port branch from ...@github.com:dpp/liftweb.git > 2. step: > cd into liftweb/lift-persistence/lift-mapper and run > mvn dependency:copy-dependencies > 3. step: > run the following command > -classpath `find target/dependency > -name *.jar | xargs scala -e 'println(args mkString ":")'` -sourcepath > src/main/scala -d target/classes `find src/main/scala -name *.scala` > This will only use Maven to download the dependencies, but you can compile > with scalac or fsc. Great! Can you provide me with a tarball or zip of the lift sources? I don't have git installed here yet. Thanks -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Martin, You can download a tarball from: http://github.com/dpp/liftweb/tree/280_port/ Go to that page and look for the "download" button. You'll be presented with the option of tar or zip. I'll also send you the tarball privately. Thanks, David On Tue, Dec 22, 2009 at 5:12 AM, martin odersky wrote: > On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth > wrote: > > I think staying in maven would require the least amount of typing, but > the > > most amount of time as you'd have to publish local snapshots of Scala > 2.8.0 > > to use them in the lift build. I remember how annoying this is ;). > Also > > note that deploying maven requires a full scala build, but if needed I > can > > make a short-cut that will just publish the "quick" libraries. This > would > > help immensely in testing trunk against projects, but is not very helpful > > otherwise. Would this be desirable? > > > > What was already suggested (runing mvn dependency:copy-dependencies) is > very > > viable. However, if lift-mapper relies on lift-util, you'll have to > > rebuild one before you rebuild the other if you're somehow changing the > ABI. > > > > If you still wanted to use maven, I recommend using the reactor plugin. > If > > you identify the project that is failing you can run: > > > > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper > > > > Where "net.liftweb:lift-mapper" is the groupId:artifactId containing the > > failing module. This will only build the lift-mapper module and other > > modules on which lift-mapper depends (i.e. if lift-mapper needs lift-util > > (and only lift-util) just those two will be built. > > > > I have a local VM where I was setting up a scala nightly build that would > > feed maven. Perhaps when I finish I'll make a write-up on how to do > this, > > or have some kind of template/script you can use to do it by hand. > > > > - Josh > > > Hi Josh, > > The problem is not so much building individual maven modules, but > building them with experimental compilers. I need to be able to put a > println into scalac, rebuild that (takes 10sec with fsc) and then > recompile the offending maven part with that compiler. That's why I > need a version of lift that can be compiled without maven. It need not > be perfect, for instance one can probably throw out all the tests. But > I need to be able to use lift as a rapid experimentation tool for the > scala compiler itself. > > Unfortunately, LAMP is pretty much shutting down for the holidays > right now. So any outside help that you can give is appreciated. > Ideally: I get the right lift version as a tarball, together with all > jars that it needs. Then, instructions what to compile in what order > (I can probably figure them out in a pinch, but if someone knows that > already, it would help). > > Thanks > > -- Martin > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Dirty solutions (If you already have maven installed and be able to build lift with maven) : 0. replace $HOME/.m2/repository/org/scala-lang/scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar by symlink to the directory with classes result from scalac scalac compilation 1. Or at the end of scalac scalac compilation create a jar and copy (override) t in place of .m2//scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar 2. Or you could run maven with the -Dmaven.scala.displayCmd=true then the command line used to build will be displayed. Copy the line into a .sh/.cmd Modifie the location scala .jar to use the output of your scalac scalac compilation. Notes : * the call of scalac is wrapped into a main able to handle a long list of arguments from file (working with any version of scala). * maven-scala-plugin was created to used classes (scalac) packaged into jar Sorry to not provide a better solution. /davidB On Tue, Dec 22, 2009 at 15:16, martin odersky wrote: > On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth > wrote: > > For curiousities sake, if you're building using fsc, are you running > scalac > > via an exploded classpath (i.e. not a JAR file?). If so, I'll try to > come > > up with a longer-term solution for this. > > Yes, exactly. My usual setup is that my output directory is the first > item on the classpath. So any files I recompile get chosen first. > > > > > If we allowed you to do the following: > > > > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala > > -Dscala.local.classpath=classfiledir > > > > would that be sufficient? We could also have this do conditional > > computation in the future. > > Does that mean that the scala compiler would then be run out of > classfiledir? Yes, that could work. > > Cheers > > -- Martin > > -- > > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
2009/12/22 David Bernard > Dirty solutions (If you already have maven installed and be able to build > lift with maven) : > > 0. replace > $HOME/.m2/repository/org/scala-lang/scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar > by symlink to the directory with classes result from scalac scalac > compilation > > 1. Or at the end of scalac scalac compilation create a jar and copy > (override) t in place of > .m2//scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar > > 2. Or you could run maven with the -Dmaven.scala.displayCmd=true then the > command line used to build will be displayed. > Copy the line into a .sh/.cmd > Modifie the location scala .jar to use the output of your scalac scalac > compilation. > The catch here is if there's a line-length limit in your OS - the classpath gets truncated and then it all goes pear-shaped... > Notes : > * the call of scalac is wrapped into a main able to handle a long list of > arguments from file (working with any version of scala). > * maven-scala-plugin was created to used classes (scalac) packaged into jar > > Sorry to not provide a better solution. > > /davidB > > On Tue, Dec 22, 2009 at 15:16, martin odersky wrote: > >> On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth >> wrote: >> > For curiousities sake, if you're building using fsc, are you running >> scalac >> > via an exploded classpath (i.e. not a JAR file?). If so, I'll try to >> come >> > up with a longer-term solution for this. >> >> Yes, exactly. My usual setup is that my output directory is the first >> item on the classpath. So any files I recompile get chosen first. >> >> > >> > If we allowed you to do the following: >> > >> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P local-scala >> > -Dscala.local.classpath=classfiledir >> > >> > would that be sufficient? We could also have this do conditional >> > computation in the future. >> >> Does that mean that the scala compiler would then be run out of >> classfiledir? Yes, that could work. >> >> Cheers >> >> -- Martin >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > -- Kevin Wright mail/google talk: kev.lee.wri...@googlemail.com wave: kev.lee.wri...@googlewave.com skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Kevin, maven-scala-plugin integrate a workaround (see note of previous mail) against the line-length limit : arguments of the main class are store in a file. /davidB On Tue, Dec 22, 2009 at 15:45, Kevin Wright wrote: > > > 2009/12/22 David Bernard > > Dirty solutions (If you already have maven installed and be able to build >> lift with maven) : >> >> 0. replace >> $HOME/.m2/repository/org/scala-lang/scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar >> by symlink to the directory with classes result from scalac scalac >> compilation >> >> 1. Or at the end of scalac scalac compilation create a jar and copy >> (override) t in place of >> .m2//scala-compiler/2.8.0-SNAPSHOT/scala-compiler-2.8.0-SNAPSHOT.jar >> >> 2. Or you could run maven with the -Dmaven.scala.displayCmd=true then the >> command line used to build will be displayed. >> Copy the line into a .sh/.cmd >> Modifie the location scala .jar to use the output of your scalac scalac >> compilation. >> > > > The catch here is if there's a line-length limit in your OS - the classpath > gets truncated and then it all goes pear-shaped... > > > >> Notes : >> * the call of scalac is wrapped into a main able to handle a long list of >> arguments from file (working with any version of scala). >> * maven-scala-plugin was created to used classes (scalac) packaged into >> jar >> >> Sorry to not provide a better solution. >> >> /davidB >> >> On Tue, Dec 22, 2009 at 15:16, martin odersky wrote: >> >>> On Tue, Dec 22, 2009 at 2:35 PM, Josh Suereth >>> wrote: >>> > For curiousities sake, if you're building using fsc, are you running >>> scalac >>> > via an exploded classpath (i.e. not a JAR file?). If so, I'll try to >>> come >>> > up with a longer-term solution for this. >>> >>> Yes, exactly. My usual setup is that my output directory is the first >>> item on the classpath. So any files I recompile get chosen first. >>> >>> > >>> > If we allowed you to do the following: >>> > >>> > mvn reactor:make -Dmake.artifacts=net.liftweb:lift-mapper -P >>> local-scala >>> > -Dscala.local.classpath=classfiledir >>> > >>> > would that be sufficient? We could also have this do conditional >>> > computation in the future. >>> >>> Does that mean that the scala compiler would then be run out of >>> classfiledir? Yes, that could work. >>> >>> Cheers >>> >>> -- Martin >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "Lift" group. >>> To post to this group, send email to lift...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> liftweb+unsubscr...@googlegroups.com >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/liftweb?hl=en. >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> > > > > -- > Kevin Wright > > mail/google talk: kev.lee.wri...@googlemail.com > wave: kev.lee.wri...@googlewave.com > skype: kev.lee.wright > twitter: @thecoda > > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Martin/Heiko,
Great if this works.
Alternately, you can also use maven ant plugin to complete avoid doing
the Maven way.
Here is the sequence:
1. Do "mvn ant:ant" at the top level. This should generate all the
requisite files necessary for ant build.
2. Look for the pathelement entry in maven-build.xml that is generated
(at the same level as pom.xml)
3. In that file, find the classpath entry for scala-library
(something like:
4. Replace that jar with the jar that is being generated out of scala build
5. Do 'ant compile' for compiling ('ant -p' would should the list of
commands)
Thanks, Indrajit
On 22/12/09 8:32 PM, Heiko Seeberger wrote:
> 2009/12/22 martin odersky >
>
>
> Great! Can you provide me with a tarball or zip of the lift sources? I
> don't have git installed here yet.
>
>
> Please find attached the relevant part of the sources.
>
> Heiko
>
> My job: weiglewilczek.com
> My blog: heikoseeberger.name
> Follow me: twitter.com/hseeberger
> OSGi on Scala: scalamodules.org
> Lift, the simply functional web framework: liftweb.net
>
> --
>
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Ok, this one works just fine, and involves least effort among the ones proposed. - Indrajit On 22/12/09 8:11 PM, Heiko Seeberger wrote: > Martin, > > OK, now I got it working (almost) without Maven: > > 1. step: > Check out 280_port branch from g...@github.com:dpp/liftweb.git > > 2. step: > cd into liftweb/lift-persistence/lift-mapper and run > mvn dependency:copy-dependencies > > 3. step: > run the following command > -classpath `find target/dependency > -name *.jar | xargs scala -e 'println(args mkString ":")'` -sourcepath > src/main/scala -d target/classes `find src/main/scala -name *.scala` > > This will only use Maven to download the dependencies, but you can > compile with scalac or fsc. > > Heiko > > -- > > You received this message because you are subscribed to the Google > Groups "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
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
I just verified that it did indeed use 2.7.7, because the generated classfiles still have version 4.1. My new strategy is to build with the last working RC3, and then recompile just the failing file with the current compiler and all lift classes on the classpath. That should work. But I need to know how to build lift with a 2.8.0 compiler. Or alternatively, if a kind soul can send me a lift 2.8.0 tarball with all the classfiles in there I can take it from there. Thanks -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Martin, I think the jetty version is incorrect in the pom.xml in test:sample. It should be: org.mortbay.jetty jetty [6.1.6,7.0) See if that works. Regards, Indrajit On 22/12/09 10:14 PM, martin odersky wrote: > Thanks for all the help. I tried to do > > mvn clean > mvn install > > After upgrading to maven 2.2.1, I got somewhere. It compiled a bunch > of packages including lift-mapper, so it seems it did not in fact take > RC6 as its compiler? > > But then it stopped due to a build error here. > > Any idea what I need to do to solve this? > > Thanks > > -- martin > > > > [INFO] [INFO] > > [INFO] [ERROR] BUILD ERROR > [INFO] [INFO] > > [INFO] [INFO] Failed to resolve artifact. > [INFO] > [INFO] Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, > 6.1.20, 6.1.21, 6.1.22] to match range [6.1.6,6.1.6] > [INFO] org.mortbay.jetty:jetty:jar:null > [INFO] > [INFO] from the specified remote repositories: > [INFO] scala-tools.org (http://scala-tools.org/repo-releases), > [INFO] central (http://repo1.maven.org/maven2), > [INFO] scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots) > [INFO] > [INFO] Path to dependency: > [INFO] 1) test:sample:war:0.1 > [INFO] > [INFO] > [INFO] > [INFO] [INFO] > > [INFO] [INFO] Trace > [INFO] org.apache.maven.lifecycle.LifecycleExecutionException: > Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20, > 6.1.21, 6.1.22] to match range [6.1.6,6.1.6] > [INFO] org.mortbay.jetty:jetty:jar:null > [INFO] > [INFO] from the specified remote repositories: > [INFO] scala-tools.org (http://scala-tools.org/repo-releases), > [INFO] central (http://repo1.maven.org/maven2), > [INFO] scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots) > [INFO] > [INFO] Path to dependency: > [INFO] 1) test:sample:war:0.1 > [INFO] > [INFO] > [INFO] at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:711) > [INFO] at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > [INFO] at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > [INFO] at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > [INFO] at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > [INFO] at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > [INFO] at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [INFO] at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [INFO] at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [INFO] at java.lang.reflect.Method.invoke(Method.java:597) > [INFO] at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > [INFO] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > [INFO] at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > [INFO] at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] Caused by: > org.apache.maven.artifact.versioning.OverConstrainedVersionException: > Couldn't find a version in [6.1H.22, 6.1.17, 6.1.18, 6.1.19, 6.1.20, > 6.1.21, 6.1.22] to match range [6.1.6,6.1.6] > [INFO] org.mortbay.jetty:jetty:jar:null > [INFO] > [INFO] from the specified remote repositories: > [INFO] scala-tools.org (http://scala-tools.org/repo-releases), > [INFO] central (http://repo1.maven.org/maven2), > [INFO] scala-tools.org.snapshots (http://scala-tools.org/repo-snapshots) > [INFO] > [INFO] Path to dependency: > [INFO] 1) test:sample:war:0.1 > [INFO] > [INFO] > [INFO] at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:374) > [INFO] at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) > [INFO] at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:316) > [INFO] at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:304) > [INFO] at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1499) > [INFO] at > org.apache.mav
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri wrote: > Martin, > > I think the jetty version is incorrect in the pom.xml in test:sample. > > It should be: > > org.mortbay.jetty > jetty > [6.1.6,7.0) > > See if that works. > But even then I only get a 2.7.7 build, which is not what I need? -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri wrote: > Martin, > > I think the jetty version is incorrect in the pom.xml in test:sample. > > It should be: > > org.mortbay.jetty > jetty > [6.1.6,7.0) > ... and, which test:sample are you referring to? Thanks -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
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
Must be effect of some scala.version property set somewhere. do "mvn -Dscala.version=2.8.0.Beta1-RC5" to enforce a different version. - Indrajit On 22/12/09 10:43 PM, martin odersky wrote: > On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri > wrote: >> Martin, >> >> I think the jetty version is incorrect in the pom.xml in test:sample. >> >> It should be: >> >> org.mortbay.jetty >> jetty >> [6.1.6,7.0) >> >> See if that works. >> > But even then I only get a 2.7.7 build, which is not what I need? > > -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On 22/12/09 10:44 PM, martin odersky wrote: > On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri > wrote: >> Martin, >> >> I think the jetty version is incorrect in the pom.xml in test:sample. >> >> It should be: >> >> org.mortbay.jetty >> jetty >> [6.1.6,7.0) >> > ... and, which test:sample are you referring to? > > Thanks > > -- Martin The test:sample:war:0.1 artifact for which it fails. By your question, I realize that you are encountering this during archetype generation. It's completely unnecessary. edit the top level pom.xml and remove all the modules other than lift-base, lift-persistence and lift-modules for now. They are really all that you need. The modules section in your top level pom.xml should have just this. lift-base lift-persistence lift-modules - Indrajit -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri wrote: > > On 22/12/09 10:44 PM, martin odersky wrote: >> >> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri >> wrote: >>> >>> Martin, >>> >>> I think the jetty version is incorrect in the pom.xml in test:sample. >>> >>> It should be: >>> >>> org.mortbay.jetty >>> jetty >>> [6.1.6,7.0) >>> >> ... and, which test:sample are you referring to? >> >> Thanks >> >> -- Martin > > The test:sample:war:0.1 artifact for which it fails. By your question, I > realize that you are encountering this during archetype generation. It's > completely unnecessary. > > edit the top level pom.xml and remove all the modules other than lift-base, > lift-persistence and lift-modules for now. They are really all that you > need. > > The modules section in your top level pom.xml should have just this. > > > lift-base > lift-persistence > lift-modules > > > > > > > > - Indrajit > > OK, that will help, I hope. But I still have no luck. When I download from http://github.com/dpp/liftweb/tree/280_port I get something that's different than the layout on the webpage. Subdirectories in dpp-liftweb-12d1bf0/ are flatter than what I see on the webpage. When I compile with 2.8 it dies because it wants jcl.Conversions which sure does not exist anymore. So it seems to me that versions are mixed up? I really need a tarball or zip with the right lift to test against! -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
I found someone who could download the repository with git. So trying again now. -- Martin On Tue, Dec 22, 2009 at 6:36 PM, martin odersky wrote: > On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri > wrote: >> >> On 22/12/09 10:44 PM, martin odersky wrote: >>> >>> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri >>> wrote: Martin, I think the jetty version is incorrect in the pom.xml in test:sample. It should be: org.mortbay.jetty jetty [6.1.6,7.0) >>> ... and, which test:sample are you referring to? >>> >>> Thanks >>> >>> -- Martin >> >> The test:sample:war:0.1 artifact for which it fails. By your question, I >> realize that you are encountering this during archetype generation. It's >> completely unnecessary. >> >> edit the top level pom.xml and remove all the modules other than lift-base, >> lift-persistence and lift-modules for now. They are really all that you >> need. >> >> The modules section in your top level pom.xml should have just this. >> >> >> lift-base >> lift-persistence >> lift-modules >> >> >> >> >> >> >> >> - Indrajit >> >> > OK, that will help, I hope. > > But I still have no luck. When I download from > > http://github.com/dpp/liftweb/tree/280_port > > I get something that's different than the layout on the webpage. > Subdirectories in dpp-liftweb-12d1bf0/ > are flatter than what I see on the webpage. When I compile with 2.8 it > dies because it wants jcl.Conversions which sure does not exist > anymore. So it seems to me that versions are mixed up? I really need a > tarball or zip with the right lift to test against! > > -- Martin > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 6:48 PM, martin odersky wrote: > I found someone who could download the repository with git. So trying > again now. ... and it builds with RC3. Great! So now I have something to work with ... Cheers -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On 22/12/09 11:06 PM, martin odersky wrote: > On Tue, Dec 22, 2009 at 6:24 PM, Indrajit Raychaudhuri > wrote: >> >> On 22/12/09 10:44 PM, martin odersky wrote: >>> >>> On Tue, Dec 22, 2009 at 6:09 PM, Indrajit Raychaudhuri >>> wrote: Martin, I think the jetty version is incorrect in the pom.xml in test:sample. It should be: org.mortbay.jetty jetty [6.1.6,7.0) >>> ... and, which test:sample are you referring to? >>> >>> Thanks >>> >>> -- Martin >> >> The test:sample:war:0.1 artifact for which it fails. By your question, I >> realize that you are encountering this during archetype generation. It's >> completely unnecessary. >> >> edit the top level pom.xml and remove all the modules other than lift-base, >> lift-persistence and lift-modules for now. They are really all that you >> need. >> >> The modules section in your top level pom.xml should have just this. >> >> >> lift-base >> lift-persistence >> lift-modules >> >> >> >> >> >> >> >> - Indrajit >> >> > OK, that will help, I hope. > > But I still have no luck. When I download from > >http://github.com/dpp/liftweb/tree/280_port > > I get something that's different than the layout on the webpage. > Subdirectories in dpp-liftweb-12d1bf0/ > are flatter than what I see on the webpage. When I compile with 2.8 it > dies because it wants jcl.Conversions which sure does not exist > anymore. So it seems to me that versions are mixed up? I really need a > tarball or zip with the right lift to test against! I just downloaded the zip from github page. Not sure how github prepares the archive. But I can confirm that dpp-liftweb-12d1bf0/ is incorrect. > > -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
Finally! Onward ... - Indrajit On 22/12/09 11:29 PM, martin odersky wrote: > On Tue, Dec 22, 2009 at 6:48 PM, martin odersky > wrote: >> I found someone who could download the repository with git. So trying >> again now. > > ... and it builds with RC3. Great! So now I have something to work with ... > > Cheers > > -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 05:45:52PM +0100, martin odersky wrote: > But I need to know how to build lift with a 2.8.0 compiler. Or > alternatively, if a kind soul can send me a lift 2.8.0 tarball with > all the classfiles in there I can take it from there. FYI until you have git you can always download a tarball snapshot of the current head at github. There's a "download" link here: http://github.com/dpp/liftweb Except you need the 280_port branch, so here: http://github.com/dpp/liftweb/tree/280_port And that download link goes here: http://github.com/dpp/liftweb/tarball/12d1bf0697c9c792c8c91416989a0ef7e287b156 Assuming that gets the files it should, typing "mvn install" will try to build with 2.80 Beta1 RC3. To use RC5 edit pom.xml with this diff: -2.8.0.Beta1-RC3 +2.8.0.Beta1-RC5 Instructions from earlier in this thread should get you to the point where you can build with the local compiler. -- Paul Phillips | Adultery is the application of democracy to love. Vivid | -- H. L. Mencken Empiricist | pull his pi pal! |--* http://www.improving.org/paulp/ *-- -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: [scala-internals] RC5 candidate for the first 2.8.0 beta
On Tue, Dec 22, 2009 at 7:12 PM, Paul Phillips wrote: > On Tue, Dec 22, 2009 at 05:45:52PM +0100, martin odersky wrote: >> But I need to know how to build lift with a 2.8.0 compiler. Or >> alternatively, if a kind soul can send me a lift 2.8.0 tarball with >> all the classfiles in there I can take it from there. > > FYI until you have git you can always download a tarball snapshot of the > current head at github. There's a "download" link here: > > http://github.com/dpp/liftweb > > Except you need the 280_port branch, so here: > > http://github.com/dpp/liftweb/tree/280_port > > And that download link goes here: > > http://github.com/dpp/liftweb/tarball/12d1bf0697c9c792c8c91416989a0ef7e287b156 > > Assuming that gets the files it should, typing "mvn install" will try to > build with 2.80 Beta1 RC3. To use RC5 edit pom.xml with this diff: > > - 2.8.0.Beta1-RC3 > + 2.8.0.Beta1-RC5 > > Instructions from earlier in this thread should get you to the point > where you can build with the local compiler. > yes I got that working. The problem was that the download at 280_port was not 280_port but (I guess) 280_dev. That got me stuck for a while, but we sorted it out eventually. Cheers -- Martin -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
