On Thu, Nov 15, 2012 at 2:51 PM, Luke Daley <[email protected]>wrote:
> > On 15/11/2012, at 1:46 PM, Szczepan Faber wrote: > > > It's not critical but it might be nice to mention in the potential > > breaking changes that we've added new tasks (like 'scalaCompile'). In > > one of the builds that I've tried with the rc, the scala projects were > > failing (task name clash) because the client has already had custom > > 'scalaComile' task. > > The issue here might be that these things were added but not documented. > > Treating the adding of task as breaking changes is a precedent we may not > want to set. > I agree. But we need at one point introduce namespaces for tasks. Hans > > > > > Cheers! > > > > On Thu, Nov 15, 2012 at 12:10 AM, Peter Niederwieser <[email protected]> > wrote: > >> Adam Murdoch wrote > >>> On 14/11/2012, at 2:30 PM, Peter Niederwieser wrote: > >>>> the combination of `useAnt=false` (i.e. Zinc) and `fork=false` doesn't > >>>> work. I implemented this because there was a concrete need to have (or > >>>> keep) > >>>> each of the other three combinations, and it felt a bit strange to > leave > >>>> out > >>>> the fourth one. I thought that by reusing the > >>>> InProcessCompilerDaemonFactory > >>>> we have for Java and Groovy, it would be trivial to implement this. > >>>> Unfortunately, I forgot to add an integration test for this case. (We > are > >>>> testing quite a few combinations by now.) As it turns out, the current > >>>> InProcessCompilerDaemonFactory has performance and correctness > problems > >>>> when > >>>> used with Scala. > >>> > >>> What are the issues? > >> > >> I haven't investigated all test failures, but one cause I've identified > is > >> class loader inconsistencies. For example, > >> `catch(CompilationFailedException)` in NormalizingScalaCompiler doesn't > >> catch anything because the `CompilationFailedException` class thrown > has a > >> different defining class loader. > >> > >> Another potential problem is that the cache loaders aren't cached, so I > >> assume we'll incur the same performance penalties as back when we > didn't use > >> a compiler daemon. > >> > >> Cheers, > >> Peter > >> > >> > >> > >> -- > >> View this message in context: > http://gradle.1045684.n5.nabble.com/Known-problems-with-new-Scala-features-in-1-3-rc-1-tp5710401p5710409.html > >> Sent from the gradle-dev mailing list archive at Nabble.com. > >> > >> --------------------------------------------------------------------- > >> To unsubscribe from this list, please visit: > >> > >> http://xircles.codehaus.org/manage_email > >> > >> > > > > > > > > -- > > Szczepan Faber > > Principal engineer@gradleware > > Lead@mockito > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
