RC5 candidate for the first 2.8.0 beta

RC5 fixes the lift build problem we saw with RC4.

On Monday 21 December 2009 22:56:37 Antonio Cunei wrote:
> Developers: please try your projects against this version and let us know.

On the 2.8.0 road I'd like to mention this [1] ticket. The main it's feauture
is: this false error arises from nowhere - there isn't any visible (and
"workaroundable") signs of a reason why this error is reported. I spent many
hours (being in frustration) during reducing real project (~170 scala files)
to few-lines test case. After the reducing I have also found a way to work
around the problem (in fact, just commenting few "protected" keywords out). So
the issue isn't a showstopper for me now. But I'd be happy to be the last
fighting in the dark ;-)

Andrew

[1] http://lampsvn.epfl.ch/trac/scala/ticket/2809

On Mon, Dec 21, 2009 at 12:21 PM, martin odersky <martin.odersky@epfl.ch> wrote:

Comment: RC5 fixes the lift build problem we saw with RC4.

Is this the refrain to the popular song "We're gettin' Scala 2.8 out the door"? ;-)

In all seriousness, thank you very much for your attention and responsiveness!

David
 

Cheers

Hi,
Thank you for your very quick response cycle!
I tried Lift against RC5 and there is a similar error like with RC4, but it happens "later" than before, hence it looks like the former error is fixed.
java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.scala_tools.maven.executions.MainHelper.runMain(MainHelper.java:151) at org.scala_tools.maven.executions.MainWithArgsInFile.main(MainWithArgsInFile.java:26) Caused by: java.lang.AssertionError: assertion failed: type error: can't convert from REFERENCE(net.liftweb.mapper.KeyedMapper) to REFERENCE(net.liftweb.mapper.KeyedMetaMapper) in unit MetaMapper.scala at scala.tools.nsc.backend.icode.GenICode$ICodePhase.adapt(GenICode.scala:943) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:927) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadArguments(GenICode.scala:1011) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:732) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadArguments(GenICode.scala:1011) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:653) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genLoadArguments(GenICode.scala:1011) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:653) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:502) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genStat(GenICode.scala:187) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$genStat$1.apply(GenICode.scala:159) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$genStat$1.apply(GenICode.scala:159) at scala.collection.LinearSeqLike$class.foldLeft(LinearSeqLike.scala:159) at scala.collection.immutable.List.foldLeft(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.genStat(GenICode.scala:159) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.scala$tools$nsc$backend$icode$GenICode$ICodePhase$$genLoad(GenICode.scala:849) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:130) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:152) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:106) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase$$anonfun$gen$1.apply(GenICode.scala:87) at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:97) at scala.collection.immutable.List.foreach(List.scala:46) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:87) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:97) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.gen(GenICode.scala:83) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.apply(GenICode.scala:79) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply(Global.scala:281) at scala.tools.nsc.reporters.Reporter.withSource(Reporter.scala:48) at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:281) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:259) at scala.collection.Iterator$class.foreach(Iterator.scala:582) at scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:285) at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:259) at scala.tools.nsc.backend.icode.GenICode$ICodePhase.run(GenICode.scala:72) at scala.tools.nsc.Global$Run.compileSources(Global.scala:749) at scala.tools.nsc.Global$Run.compile(Global.scala:839) at scala.tools.nsc.Main$.process(Main.scala:109) at scala.tools.nsc.Main$.main(Main.scala:123) at scala.tools.nsc.Main.main(Main.scala) ... 6 more
Best regards,
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

On Tue, Dec 22, 2009 at 8:34 AM, Heiko Seeberger
wrote:
> Hi,
> Thank you for your very quick response cycle!
> I tried Lift against RC5 and there is a similar error like with RC4, but it
> happens "later" than before, hence it looks like the former error is fixed.
> java.lang.reflect.InvocationTargetException

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.

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.

Cheers

2009/12/22 martin odersky <martin.odersky@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
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

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.

2009/12/22 martin odersky <martin.odersky@epfl.ch>

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

On Tue, Dec 22, 2009 at 12:18 PM, Heiko Seeberger
wrote:
> 2009/12/22 martin odersky
>>
>> >>
>> >> 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
>
> In the end this should be possible, but you will have to set up the
> classpath appropriately (dependency management and resolution is one of
> Maven's core capabilities). I do not know how to accomplish this within a
> reasonable time frame, but maybe there are some tricks to get the build
> classpath from Maven for you somehow. Therefore I am CCing our Maven god
> Indrajit, maybe he knows ...
> Heiko
>
First, what version of lift do I need? I tried 1.1 M8, but that's
still a Scala 2.7 system. Then, my main problem are the other tools
that are referenced out of lift. So I am not sure we can get there
easily.

Another route to take would be to distill a small example that shows
the error and that does not have all these dependencies. That will
take time also.

But it seems we are out of easy options now.

$ mvn dependency:resolve

will download all dependency jars under target/ folder (or some sub
folder of it).

Of course, you still have to use maven. For this reason, I am not sure
how helpful this step is.

BR
Christos

On Tue, Dec 22, 2009 at 13:18, Heiko Seeberger
wrote:
> 2009/12/22 martin odersky
>>
>> >>
>> >> 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
>
> In the end this should be possible, but you will have to set up the
> classpath appropriately (dependency management and resolution is one of
> Maven's core capabilities). I do not know how to accomplish this within a
> reasonable time frame, but maybe there are some tricks to get the build
> classpath from Maven for you somehow. Therefore I am CCing our Maven god
> Indrajit, maybe he knows ...
> 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
>

2009/12/22 martin odersky <martin.odersky@epfl.ch>

First, what version of lift do I need? I tried 1.1 M8, but that's
still a Scala 2.7 system. Then, my main problem are the other tools
that are referenced out of lift. So I am not sure we can get there
easily.

Not sure how your approach looks like, but if you use the 280_port branch from the GitHub repository you will get everything you need for Maven. Just open the root pom.xml and change the scala.version property from RC3 to RC4 or RC5. Then enter mvn clean install, go away to get some coffee and come back to see lift-mapper fail. Then you can cd into lift-persistenct/lift-mapper and enter mvn compile in order to only build the lift-mapper module which will be pretty fast compared to what you experience when building Lift as a whole.  

Another route to take would be to distill a small example that shows
the error and that does not have all these dependencies. That will
take time also.

I am not sure if that is possible, at least I cannot isolate the problem such that there are no more dependencies.
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

$ mvn dependency:resolve

will download all dependency jars under target/ folder (or some sub
folder of it).

Thank you!The goal is dependency:copy-dependencies and it will put the libs unter target/depency by default. 

Of course, you still have to use maven. For this reason, I am not sure
how helpful this step is.

You could use scalac now and set the classpath to all the above libs. But I do not know whether scalac can operate on a source directory to compile all sources (e.g. using a wildcard) ... If not, you had to specify all the source files manually and that looks like a huge pain.
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



--
Heiko Seeberger

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

On Tue, Dec 22, 2009 at 13:07, Heiko Seeberger <heiko.seeberger@googlemail.com> wrote:

$ mvn dependency:resolve

will download all dependency jars under target/ folder (or some sub
folder of it).

Thank you!The goal is dependency:copy-dependencies and it will put the libs unter target/depency by default.  

Of course, you still have to use maven. For this reason, I am not sure
how helpful this step is.

You could use scalac now and set the classpath to all the above libs. But I do not know whether scalac can operate on a source directory to compile all sources (e.g. using a wildcard) ... If not, you had to specify all the source files manually and that looks like a huge pain.

that's pretty simple usingscalac `find /path/to/src -name *.scala` 

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



--
Heiko Seeberger

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

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

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

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.bears@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.odersky@epfl.ch> wrote:

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

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

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

On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth <joshua.suereth@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

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.suereth@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.odersky@epfl.ch> wrote:

On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth <joshua.suereth@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

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

that's pretty simple usingscalac `find /path/to/src -name *.scala`

You are right ;-)
The missing piece then is:How can we create the classpath out of all the JARs in target/depencency?find target/depencency -name *.jar will result in a list with a line for each, but we need something like jar1:jar2:...
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

$ find jars -name \*.jar | xargs scala -e 'println(args mkString ":")'

On Tue, Dec 22, 2009 at 16:22, Heiko Seeberger
wrote:
>> that's pretty simple using
>> scalac `find /path/to/src -name *.scala`
>
> You are right ;-)
> The missing piece then is:
> How can we create the classpath out of all the JARs in target/depencency?
> find target/depencency -name *.jar will result in a list with a line for
> each, but we need something like jar1:jar2:...
> 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
>

Hi Martin,
FWIW, when I worked on that other lift bug, I simply symlinked the jars maven uses to call the scala compiler to my working copy, on my mac they're in under ~/.m2/repository (I have no idea where they are on Windows)
$ pwd
/Users/adriaan/.m2/repository/org/scala-lang/scala-compiler/2.8.0.Beta1-RC1
$ ls -lh .
scala-compiler-2.8.0.Beta1-RC1.jar -> /Users/adriaan/git/scala/build/pack/lib/scala-compiler.jar
to recompile I use ant pack.done and then invoke whatever maven commands necessary to do the rebuild(On Windows, I guess you could replace the symlink step with copying the actual jar every time you run ant pack.done..)
hope that helpsadriaan

Martin,
OK, now I got it working (almost) without Maven:
1. step:Check out 280_port branch from git@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

I love the way it's a smiley at the end there :")

2009/12/22 Christos KK Loverdos <loverdos@gmail.com>

$ find jars -name \*.jar | xargs scala -e 'println(args mkString ":")'


On Tue, Dec 22, 2009 at 16:22, Heiko Seeberger
<heiko.seeberger@googlemail.com> wrote:
>> that's pretty simple using
>> scalac `find /path/to/src -name *.scala`
>
> You are right ;-)
> The missing piece then is:
> How can we create the classpath out of all the JARs in target/depencency?
> find target/depencency -name *.jar will result in a list with a line for
> each, but we need something like jar1:jar2:...
> 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
>



--
 __~O
 -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

--
Kevin Wright

mail/google talk: kev.lee.wright@googlemail.com
wave: kev.lee.wright@googlewave.com
skype: kev.lee.wright
twitter: @thecoda

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 git@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 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.odersky@epfl.ch> wrote:

On Tue, Dec 22, 2009 at 2:01 PM, Josh Suereth <joshua.suereth@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

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

Arrggg, this was an invalid ZIP.
Here comes a better one ...

2009/12/22 Heiko Seeberger <heiko.seeberger@googlemail.com>

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

--
Heiko Seeberger

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

On Tue, Dec 22, 2009 at 04:29:11PM +0200, Christos KK Loverdos wrote:
> $ find jars -name \*.jar | xargs scala -e 'println(args mkString ":")'

Way to use scala in the pipeline. Another option (which I mention
because if line length is an issue, this has no issue) is

mkdir lib ; cp `find jars -name '*.jar'` lib ; scalac -cp 'lib/*' ...

Tangent: little known fact is that at some point I made that argument
apply a java regexp except that your '*' is translated to java's '.*',
so you can say e.g.

scala -cp 'gdata-calendar*'

and only get matching jars on the classpath.

OK, I think I have found and fixed the issue. Can't guarantee there
are no others, though. Heiko, is it possible to test the lift build
also with the nightly build? In that case, you should be able to test
it with the Dec23rd build, provided my checkin (r20300) succeeds.
Please let me know how it goes.

Cheers

On Tue, Dec 22, 2009 at 5:00 PM, martin odersky <martin.odersky@epfl.ch> wrote:

OK, I think I have found and fixed the issue. Can't guarantee there
are no others, though. Heiko, is it possible to test the lift build
also with the nightly build? In that case, you should be able to test
it with the Dec23rd build, provided my checkin (r20300) succeeds.
Please let me know how it goes.

Martin,

Thanks!

David
 

Cheers

On Wed, Dec 23, 2009 at 02:00:31AM +0100, martin odersky wrote:
> OK, I think I have found and fixed the issue. Can't guarantee there
> are no others, though. Heiko, is it possible to test the lift build
> also with the nightly build? In that case, you should be able to test
> it with the Dec23rd build, provided my checkin (r20300) succeeds.
> Please let me know how it goes.

I don't know how to run tests beyond "mvn test", but to my eye it passed
with flying colors.