SBT issue with play! framework, NB not picking the classes generated from the templates
rcano opened this issue · comments
The title says it all, play has a build system where templates are transformed into scala classes and then compiled, which in turn become part of the classpath, and so your code can depend on them. NB is not picking this up. From what I understand, what would be missing is the src_managed and classes_managed that sbt has. Adding this to the CP should fix it. I'm going to test this by modifying the classpath_nb by hand
Couldn't make it work modifying the classpath_nb.
Correction, it actually worked, but only for scala classes, java classes still report errors when you try to use the classes generated for the templates.
Did you added both java and scala src folder to .classpath_nb? The error is seen from Java when refer a Scala class or from Scala when refer a java class?
Play does not generate java classes, only scala, and it places them under target/scala_2.10/src_managed/main, which I tried adding and scala classes saw them, but not java classes. The entry I added is:
With respect to the second question it would be, the error is seen from Java when refer a Scala class auto generated in this src_managed dir
The last comment ate my entry, lets try again:
<classpathentry scope="compile" output="target/scala-2.10/classes_managed" path="target/scala-2.10/src_managed/main" kind="src"></classpathentry>Just pushed fixes, including nbscala's 5f85ac6 and dcaoyuan/nbsbt@ 6935089e17600d2c687d6ae13d76f20d52415988
I'm not sure if I got things correct, please try and feed back.
Ok, pulled both projects, and installed. Issue still persists. I checked the classpath_nb since I expected some changes, but there was nothing new in it.
There should be a new tag "managed" if new nbsbt was successfully upgraded.
sbt's plugin version is difficult to maintain during developing, I guess your old 1.0.2 nbsbt is still under cached etc. You may try to cheat it by increase the nbsbt version number to 1.0.2.1 or if 4 digit number is not accepted by sbt, change it to 1.0.3
Tried this, and nothing.
On Fri, Mar 8, 2013 at 3:03 PM, Caoyuan Deng notifications@github.comwrote:
sbt's plugin version is difficult to maintain during developing, I guess
your old 1.0.2 nbsbt is still under cached etc. You may try to cheat it by
increase the nbsbt version number to 1.0.2.1 or if 4 digit number is not
accepted by sbt, change it to 1.0.3—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-14630823
.
Did you:
sbt clean compile publish-local
on nbsbt?
The last commit:
dcaoyuan/nbsbt@6935089
indicates that I've successfully pushed it to github.
On Sat, Mar 9, 2013 at 1:36 AM, rcano notifications@github.com wrote:
Tried this, and nothing.
On Fri, Mar 8, 2013 at 3:03 PM, Caoyuan Deng notifications@github.comwrote:
sbt's plugin version is difficult to maintain during developing, I guess
your old 1.0.2 nbsbt is still under cached etc. You may try to cheat it
by
increase the nbsbt version number to 1.0.2.1 or if 4 digit number is not
accepted by sbt, change it to 1.0.3—
Reply to this email directly or view it on GitHub<
https://github.com/dcaoyuan/nbscala/issues/73#issuecomment-14630823>
.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-14632665
.
I can verify that adding that entry by hand does make NB typecheck the java classes
Here is an example that I create via nbsbt automatically on akka sbt
project (notice the 'managed' tag)
On Sat, Mar 9, 2013 at 2:16 AM, rcano notifications@github.com wrote:
I can verify that adding that entry by hand does make NB typecheck the
java classes—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-14634770
.
Right, sorry for the noise, it was a cached version of the plugin, which strangely keep the problem when I published with a newer version. I removed from my ~/.ivy2/local the plugin, and re published, and it worked. Thanks a lot.
Wait, the output tag is wrong, it points to target/scala-2.10/classes, instead of target/scala-2.10/classes_managed, which still causes the problem in java classes.
From sbt document, there is only classDirectory as the output setting key,
there is no managedClassDirectory or any other settings that could tell me
where will be the output classes path for managedSources.
On Sat, Mar 9, 2013 at 2:30 AM, rcano notifications@github.com wrote:
Wait, the output tag is wrong, it points to target/scala-2.10/classes,
instead of target/scala-2.10/classes_managed, which still causes the
problem in java classes.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-14635470
.
BTW, since IDE is using to edit/probe only, as I've added managed sources
to the internal compiler setting, that is, the output directory may not be
so important for IDE anymore. When you build sbt project, you always launch
a sbt process, which will re-do a full compilation and put classes to where
they should be.
On Sat, Mar 9, 2013 at 2:56 AM, Caoyuan dcaoyuan@gmail.com wrote:
From sbt document, there is only classDirectory as the output setting key,
there is no managedClassDirectory or any other settings that could tell me
where will be the output classes path for managedSources.On Sat, Mar 9, 2013 at 2:30 AM, rcano notifications@github.com wrote:
Wait, the output tag is wrong, it points to target/scala-2.10/classes,
instead of target/scala-2.10/classes_managed, which still causes the
problem in java classes.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-14635470
.
Ok, but still the java classes will report error when mentioning the classes generated by the templates, which as you say, are located in the managed sources. For some reason, their structure is not being published to java classes, and when I change by hand the output directory of the managed classes, to the classes_managed, the java classes finally work.
Thanks for the information, I'll try to find a way to get the output path
setting of managed sources.
On Sat, Mar 9, 2013 at 5:20 AM, rcano notifications@github.com wrote:
Ok, but still the java classes will report error when mentioning the
classes generated by the templates, which as you say, are located in the
managed sources. For some reason, their structure is not being published to
java classes, and when I change by hand the output directory of the managed
classes, to the classes_managed, the java classes finally work.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-14646109
.
Did you find any clue in your project definition file (*.sbt or Build.scala
etc) that explicitly specifies the output(classes) path of the managed
source?
Actually, for my understanding, the Scala's compiler settings only accept
one output path, which is sth. like:
settings.outdir.value = outputPath
On Sat, Mar 9, 2013 at 5:29 AM, Caoyuan dcaoyuan@gmail.com wrote:
Thanks for the information, I'll try to find a way to get the output path
setting of managed sources.On Sat, Mar 9, 2013 at 5:20 AM, rcano notifications@github.com wrote:
Ok, but still the java classes will report error when mentioning the
classes generated by the templates, which as you say, are located in the
managed sources. For some reason, their structure is not being published to
java classes, and when I change by hand the output directory of the managed
classes, to the classes_managed, the java classes finally work.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-14646109
.
I'm investigating the issue too. Like you said, there is no managed classpath setting.
Since I'll be busy during weekend, I'll come back to you on Monday. Thanks for your dedication.
It keeps getting weirder, the under classes_managed are actually copied over to classes, that is, play must probably be compiling them to a personal directory for some reason, but later they move it to the stanrdard output directory classes, so there is no reason why NB is not seeing them. I'm more puzzled now.
Since the managed sources will be re-created each time, you can try to
right-click on an opening editing windows and choose "Reset Scala Compiler"
when these sources created again (this editing windows should be one of the
source file of your project). Then, switch to another editing window and
switch back. This is the last trying method when something is wrong.
If above hint works, then the issue may be caused by the re-created source
folder each time.
On Sat, Mar 9, 2013 at 5:52 AM, rcano notifications@github.com wrote:
It keeps getting weirder, the under classes_managed are actually copied
over to classes, that is, play must probably be compiling them to a
personal directory for some reason, but later they move it to the stanrdard
output directory classes, so there is no reason why NB is not seeing them.
I'm more puzzled now.—
Reply to this email directly or view it on GitHubhttps://github.com//issues/73#issuecomment-14647639
.
Didn't work.
It may be caused by wrong settings of src folders in my Scala compiler (the global), I pushed fixes: 2f00a9c
I just pulled and tried, it didn't work.
As I said in a previous comment, it makes no sense that we have to add this managed classes directory, because the classes are already in the standard classes directory. I would suggest for now ignoring the problem, and maybe a warning note somewhere in the doc, specifying this known issue with java classes referencing classes generated by play, and that the known workaround is to alter the classpath entry for the managed source so that its output tags targets the target/scala_xx/classes_managed directory.
As the error is seen in a Java source file, when referring a generated Scala source in the managed sources folder, this issue is from uncompleted work that is going to translate Scala source to virtual Java source. You know, as the source form instead of compiled class, Java editor/compiler does not understand Scala sources, under NetBeans, there is a mechanism called VirtualSourceProvider, where I try to translate each public/protected classes/methods to a virtual Java file, so the background javac will compile this virtual java file and feed back to editing java sources.
It's a complex work, I've done about half of them, and get a importance fix in mentioned push. You can try to clear/delete the NetBeans' cache, and re-start it, it will re-scan all related Scala sources and do the translating, afterwards, any modification on Scala source file will trigger re-scan/re-translate when you press "save".
If you see some of the Scala classes/methods are correctly recognized in Java file, then this issue can be closed and we'll re-open a new issue referring un-recognized Scala classes/methods in Java file.
BTW, the netbeans cache place could be got from netbeans_installation/etc/netbeans.conf file
Hi
I have similar problem, but with Maven project. I'm developer of Play! Framework 2.x Maven plugin (https://code.google.com/p/play2-maven-plugin/) which works similar to SBT.
First, I know quite well, how Play! build works internally and would like to clarify 'classes_managed' problem.
- When Play! processes templates it generates Scala files in
target/scala_2.10/src_managed/maindirectory. - Compilation writes all class files to
target/scala_2.10/classesdirectory. - Classes being products of generated Scala sources (determined using SBT incremental compilation cache files) are copied from
classestoclasses_managed.
classes_managed directory should be added to classpath only in IDE's not supporting Scala,
IDEs supporting Scala should ignore this directory. Instead target/scala_2.10/src_managed/main should be added as additional source root.
Not back to my problem. Maven projects have strange limitations when dealing with generated sources. Netbeans messgae says "Any source roots generated by Maven will be generated into the ${basedir}/target/generated_sources/FOOBAR folder ...". Play! Maven plugin mimics SBT, so Scala files are generated in target/scala_2.10/src_managed/main.
I could add parametrization of this location in the plugin, but I would like to avoid it. Can you propose any other solution?
BTW, I opened simple SBT project https://github.com/playframework/playframework/tree/2.3.8/samples/scala/helloworld on Windows, but it does not work at all. NB tries to find "sh", but this is not a Linux :) Exception thrown:
java.io.IOException: Cannot run program "sh[ERROR] Failed to construct terminal; falling back to unsupported