Open GoogleCodeExporter opened 9 years ago
It's not a bug.
In SBT (like in Maven) you can define many additional source compilation roots
(in Maven for example by using
http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html).c
Every Maven project has one predefined location, usually "src/main/java". Of
course you can change it in "<project><build><sourceDirectory>" element of
"pom.xml" file.
In SBT there are more predefined source roots:
- "src/main/java"
- "src/main/scala"
- "target/src_managed/main"
You or plugins used in your project can add additional source roots just like
in Maven. Twirl adds its own "target/{scala-version}/twirl/main, but it's not
necessary.
For reference:
SBT (version 0.13.6):
sourceManaged := crossTarget.value / "src_managed"
https://github.com/sbt/sbt/blob/0355362ffbae9dcea1f805c1412dcaf4ce732b35/main/sr
c/main/scala/sbt/Defaults.scala#L170
sourceManaged <<= configSrcSub(sourceManaged)
https://github.com/sbt/sbt/blob/0355362ffbae9dcea1f805c1412dcaf4ce732b35/main/sr
c/main/scala/sbt/Defaults.scala#L178
managedSourceDirectories := Seq(sourceManaged.value)
https://github.com/sbt/sbt/blob/0355362ffbae9dcea1f805c1412dcaf4ce732b35/main/sr
c/main/scala/sbt/Defaults.scala#L184
Twirl (version 1.0.2):
target in compileTemplates := crossTarget.value / "twirl" /
Defaults.nameForSrc(configuration.value.name)
https://github.com/playframework/twirl/blob/v1.0.2/sbt-twirl/src/main/scala/play
/twirl/sbt/SbtTwirl.scala#L50
managedSourceDirectories <+= target in compileTemplates
https://github.com/playframework/twirl/blob/v1.0.2/sbt-twirl/src/main/scala/play
/twirl/sbt/SbtTwirl.scala#L55
I decided not to complicate the logic and the differences between different
Play! lines more than it's required and never had any problems.
The issue you cited
(https://github.com/playframework/playframework/issues/2263) is not related to
this.
Did you have any problems with your builds or just found the difference between
SBT and Maven implementation?
Original comment by gslowiko...@gmail.com
on 16 Oct 2014 at 7:53
Yes I actually had some problems using ./activator <cmd> after compiling with
the maven plugin.
I've added
<delete dir="${project.build.directory}/src_managed" />
for rpm building.
I have another question, it's more related to sbt, I don't understand why sbt
download for
I added that line
resolvers += "Local Maven Repository2" at "file://" +
Path.userHome.absolutePath + "/.m2/repository"
I tried to override the resolvers doing things like
resolvers := Seq("Local Maven Repository2" at "file://" +
Path.userHome.absolutePath + "/.m2/repository") ++ resolvers
Couldn't come up with a solution, do you have any idea on how to solve that,
meaning to look first in the local maven repository or even to get ride of the
.ivy/ folder ?
I started working on the template project. I'll send you the link as soon as
it's available.
Original comment by patr...@rbcplatform.com
on 17 Oct 2014 at 11:24
I've added target in compileTemplates := file("target/src_managed/main")
in my sbt build file.
But the templates are still compiled in twirl directory.
Original comment by patr...@rbcplatform.com
on 17 Oct 2014 at 11:31
from my comment about resolvers
what I meant is that sbt always download first from repo1.maven.org I'd like it
to look first in my local maven repository.
Original comment by patr...@rbcplatform.com
on 17 Oct 2014 at 11:33
I see we have many issues here. I will try to respond to all.
1.
I will probably parametrize output directory in "template-compile" mojo
2. This works:
target in (Compile, TwirlKeys.compileTemplates) := target.value / "src_managed"
/ "main"
3. Why you need Maven local repository resolver first? What problems do you
have? What's the problem with ".ivy/" folder?
4. Why you nned to delete "src_managed" for rpm building?
I think, it would be best to attach here example project showing all problems.
Original comment by gslowiko...@gmail.com
on 19 Oct 2014 at 9:09
The sample project:
https://github.com/PatrickSauts/play235-scala211-scoverage-rpm-site
Original comment by patrick....@gmail.com
on 20 Oct 2014 at 10:20
2. This works fine for me to
3. to avoid downloading from the web again and again, as most of the
dependencies are already in my local maven repository
4. It was because it was failing building the RPM because of the templates
compiled in that directory. It was resolved by 2
Original comment by patrick....@gmail.com
on 20 Oct 2014 at 10:54
Original issue reported on code.google.com by
patrick....@gmail.com
on 15 Oct 2014 at 9:25