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.ch>wrote: > >> 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.
