sbt 0.13
shiphrah opened this issue · comments
it would be great, if sbt.013 would be supported :-)
I vote for this too. Johannes, it would be great if you rebuild and publish the plugin for SBT 0.13
I had to switch to 0.13 because of scala macros paradise plugin.
Because of popular demand I took a quick look into it. It is quite hard to get this working properly. The problem with sbt-twirl is its version complexity. Since sbt 0.13 is now on Scala 2.10 it might be easier, but the basic problem is that sbt-twirl has a) an sbt plugin b) a library, twirl-compiler, that the plugin depends on and which itself depends on the Scala compiler c) a runtime part which has to be built for the target Scala version. Also our fork currently lags behind the official play-template version quite a bit which means we are missing the Scala 2.10 support in the twirl-compiler.
Long story short: there are some ongoing considerations about the future of twirl so most likely there will be some solution eventually but unfortunately in the short-term we have no capacity to solve this issue.
+1
I had to update to SBT 0.13 and run into the same problem. So i've made a quick-oneHour-hard-fix for sbt 0.13 + scala 2.10.2, suits as a temporary solution for projects highly dependent on Twirl - https://github.com/4lex1v/twirl.
@4lex1v cool. Did you backport changes from the play project manually?
@jrudolph Yes, but i took only critical parts, to make Twirl work
@jrudolph So in other words, if I was going to need a templating engine real soon(tm) that I could rely on being maintained for the foreseeable future, look somewhere else? I realize that might be a difficult (or even loaded) question, but I'd love to hear a little bit more about the "ongoing considerations about the future of twirl". I don't mind having a somewhat moving target (hey, I usually build against the spray nightlies) but if it might get abandoned, I should probably look at something else :)
Njal,
to the best of our current knowledge twirl will not go away and will be supported for the foreseeable future.
The "ongoing considerations about the future of twirl" Johannes mentioned did/do not revolve our whether to support/evolve twirl, but who will be the one responsible for it.
+1 for resolving this issue... I managed to use twirl without "downgrading" my sbt 0.13 project creating another artifact responsible just for templating in sbt 0.12 and adding it as a depency in the main project. But is a few extra commands of sbt (publish and reload original) every time. Anyway, any change now that typesafe and spray are joined?
+1
I'm tempted to give another +1 since this would be really helpful, but I also understand the scope of the problem. So, instead I'll ask: is there anything we can do as part of the community to help move this forward? Would it be worth continuing the work @4lex1v began adding in the latest Play updates and submitting a PR? I suspect that doesn't address some of the other issues @jrudolph described.
Also of interest: does the akka acquisition of spray and that play will be
running on top of it change anything? Any chance of play itself making the
templates a standalone, reusable project or is that a pipe dream?
On Oct 28, 2013 11:57 PM, "Thomas Lockney" notifications@github.com wrote:
I'm tempted to give another +1 since this would be really helpful, but I
also understand the scope of the problem. So, instead I'll ask: is there
anything we can do as part of the community to help move this forward?
Would it be worth continuing the work @4lex1v https://github.com/4lex1vbegan adding in the latest Play updates and submitting a PR? I suspect that
doesn't address some of the other issues @jrudolphhttps://github.com/jrudolphdescribed.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/15#issuecomment-27265025
.
https://github.com/playframework/twirl
From the spray-users mailing list, this is the repo to keep an eye on. I don't know how it affects this bug, but it's relevant.
@dkowis Thanks for the pointer -- I hadn't yet looked at Twirl (though, unbeknownst to me, others in our org had already started using it) when the announcement of Spray joining Typesafe was made, so that point completely passed me by without my noticing it. For those of you wanting to see where this was mentioned, it was in @sirthias' long response to numerous questions (https://groups.google.com/d/msg/spray-user/IEVLn2ixAMQ/jSI5mA7VwFMJ), the specific quote being:
> Also of note, could twirl become a real thing separated from the Play infrastructure? :)
Yes, twirl will live on and probably be officially supported.
The Play team is going to adopt it, watch this repository: https://github.com/playframework/twirl
Just wanted to save anyone else the trouble of tracking this down. ;~)
I guess I'll be taking my questions to the Play mailing list, next!
Btw, for anyone else interested in this issue, I did finally post something on the Play mailing list: https://groups.google.com/forum/#!topic/play-framework/YXQk72btIXM
Please chime in if you have the time and anything to add, even if it's just supporting the desire to get some kind of input on where things stand. Though it's not a major roadblock, this is currently holding up some small part of our work as we try to figure out the right way to move forward given the indefinite status of this. Not that I'm suggesting it's anyone's responsibility to solve this problem for us. But I am hoping for some input from either the Spray or Play teams on how the community should approach usage of this library.
+1
Thanks @4lex1v. With one tweak (https://github.com/4lex1v/twirl/pull/1) your fork worked great for me.
I hope we get to see an official release soon.
+1
+1
+1
Jesus, now every moron will spam every subscriber with useless "+1" comment.
@CPPExpert
I'm just trying to show my interest in solution. If you have it - provide it, otherwise you are the same as me (moron)
No, I'm not the same. The bug is 5 months old. It's been noticed by maintainers. There is temporary solution provided by other user. All I want to know is when its status changes to "Closed", not when another dude is compelled to make useless comment. So STFU.
+1. If the kinda-sorta working 0.13.0 code is already there, it would be nice if it could be put somewhere people like me could depend upon =)
@4lex1v, would you contribute your branch and sign the typesafe CLA? I would then make an attempt to release a version for 0.13 even if this would be only transitory.
You can sign the CLA here: http://typesafe.com/contribute/cla/
@jrudolph of course, not a problem
Thanks, cool.
I incorporated recent changes from play into a new version. Many thanks @4lex1v for doing the main part of the merge! 🍰 I published a new 0.7.0-SNAPSHOT version which should work for sbt 0.12 and 0.13. Whoever is interested: Can you give it a try?
You'll have to add this to plugins.sbt:
resolvers += Classpaths.sbtPluginSnapshots
addSbtPlugin("io.spray" % "sbt-twirl" % "0.7.0-SNAPSHOT")The version is built from this branch: https://github.com/spray/twirl/commits/i/15/try-to-convert-to-sbt-0.13
worked for me, but i had to add
resolvers += "Spray IO Release Repo" at "http://repo.spray.io"
to my application that was depending upon my twirl compiled package otherwise the twirl-api could not be resolved, is this expected?
Strange, Twirl.settings should already add the resolver. Can you remove your explicit resolver again and post the output of running show resolvers on the sbt console for the project?
I'll just chip in here and say it works for me out of the box. Thanks @jrudolph!
Would be nice if it was a bit more flexible (e.g. working for both main/twirl and test/twirl out of the box) but nothing a bit of SBT can't fix
@jrudolph not sure, maybe i'm doing something wrong. My template project has this in project/twirl-plugin.sbt:
resolvers += Classpaths.sbtPluginSnapshots
addSbtPlugin("io.spray" %% "sbt-twirl" % "0.7.0-SNAPSHOT" )
and this in the build.sbt:
seq(Twirl.settings: _*)
that builds fine.
My application references my template project, if i put a
Twirl.settings
i get an error on sbt load: "/home/cdamour/Code/scalaES/build.sbt:27: error: not found: value Twirl Twirl.settings"
If i add the resolver then it fails at compile (because sbt.ResolveException: unresolved dependency: io.spray#twirl-api_2.10;0.7.0-SNAPSHOT: not found)
@jrudolph I don't need to add resolvers:
$ sbt show:resolvers
Loading /Users/dzsessona/utils/svm/install/0.13.0/bin/sbt-launch-lib.bash
[info] Loading project definition ..........
[info] Set current project to .........
[info] List(repo.spray.io: http://repo.spray.io)
but does not compile (find the templates), as from the documentation i have a test template in:
/src/main/twirl/org/example/hello.scala.txt
and calling as:
org.example.txt.hello("blah", "blah")
gives me: object example is not a member of package org
@kinkadzs i found my compiled templates in a namespace location different than the docs. My template was in src/main/twirl/views/helper/bootstrap3/input.scala.html and i found the compiled class at views.html.helper.bootstrap3.input
if that's how it's working, do you see your class at org.txt.example.hello ?
@drdamour nope, i don't see it anywhere, and i cannot see it compiling during sbt compile either... it is like it doesn't find any templates.... after compiling i don't even have an org folder in /target...
the only thing that i can see and that makes sense is target/scala-2.10/src_managed/main/generated-twirl-sources/
... but is empty !
@kinkadzs Can you create a new issue (or post on the Spray ML) and post a project to reproduce this issue?
@jrudolph Sure no problem. I will strip out the business logic and will post the project, Will do it today after work (in few hours). Btw thank you guys for helping.
I works nice for me also, as for twirl logging during the compilation, it was removed from original compiler, but that's not hard to add some logging like it was done previously.
@jrudolph @drdamour I created this new test project and everything works fine out of the box.
https://github.com/kinkadzs/twirlsbt13
So in the previous project I had a dependency problem and now is fixed also. Everything works now. Anyway will leave that little project for a while as small example in case someone needs it.
THANK YOU !
Thanks, @kinkadzs, I'll add it to the README.
@4lex1v, ah, I found that logging quite useful, so maybe I'll add it back.
@jrudolph I think it would be better to make logging as a build setting, cause in my case it was quite annoying, when you have many small scala.html files
Released with new version 0.7.0. Thanks for all the help and input !
Fantastic work. Thanks!
On Mar 17, 2014 9:20 AM, "Johannes Rudolph" notifications@github.com
wrote:
Reply to this email directly or view it on GitHubhttps://github.com//issues/15
.