Another possibility is to specify scala as a system dependency in Lift's

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:
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
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to