Re: [sbt-dev] Are src_managed supposed to be compiled to classes_managed?
95 views
Skip to first unread message
Ben McCann
Mar 23, 2015, 4:58:15 PM3/23/15
to sbt...@googlegroups.com, play-fram...@googlegroups.com
Thanks for the response, Eugene.
Play generates sources for its routes and views into src_managed, which then get compiled to classes_managed. I'd assumed that was the SBT default, because I don't see any reference to classes_managed in Play except for where it's adding classes_managed to the Eclipse classpath. I'd really like to understand where this behavior is coming from in Play if it's not the default.
Thanks,
Ben
On Mon, Mar 23, 2015 at 1:22 PM, eugene yokota <eed3...@gmail.com> wrote:
--On Mon, Mar 23, 2015 at 1:51 PM, Ben McCann <benjamin...@gmail.com> wrote:I thought that files in src_managed always get compiled to classes_managed?
Where did you see that?From the compiler's perspective, source is just source.After it goes through it everything should go into target/scala-xx/classes.-eugene
You received this message because you are subscribed to a topic in the Google Groups "sbt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sbt-dev/ip86t7Biw_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CA%2BCq6KQk8QDWjO8XNTi_Zp8GFEbUPh4w9HHUYvqhw6UhebiQDg%40mail.gmail.com.
James RopR
Mar 23, 2015, 6:01:32 PM3/23/15
to Ben McCann, sbt-dev, play-fram...@googlegroups.com
Hi Ben,
I believe that classes_managed was a hack for IDEs so they didn't need to support Scala - the idea being that Play copies the compiled templates and routes files to the classes_managed directory, and then the IDE can use that as a library, and doesn't need to compile scala code. I think the task that does the copying is now gone (that may have been my fault when I pulled ebean out of Play).
Cheers,
James
--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ben McCann
Mar 27, 2015, 11:52:30 AM3/27/15
to sbt...@googlegroups.com, play-fram...@googlegroups.com
The classes_managed idea really is a pretty good one for IDE support. The IDE needs either src_managed or classes_managed to be on the classpath. You don't necessarily want to see the src_managed sources in the IDE though because you never edit them since they are generated.
What do the SBT devs think about creating a classes_managed? I've done quite a bit of work on sbteclipse lately and really think it'd be helpful for us there
-Ben
On Mon, Mar 23, 2015 at 3:55 PM, Ben McCann <b...@benmccann.com> wrote:
Thanks James. I filed a bug to deal with classes_managed since it sounds like it's probably broken in Play 2.4. I can't find where it was removed though. I don't see it in the Play 2.3.x branch either... I'm really curious where this was being done.The classes_managed idea might make sense for other SBT projects besides just Play especially when we're doing IDE building via sbt-remote-control.Thanks!-Ben
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CABY0rKN7-FSLS%2BQw%2BbmGv35pMVfjNvLn5smdtV8QBQ4ucUEu9g%40mail.gmail.com.
Mirco Dotta
Mar 28, 2015, 5:45:38 AM3/28/15
to Ben McCann, sbt...@googlegroups.com, play-fram...@googlegroups.com
+1
This is really needed for using Play w/ Java inside Eclipse. Without it, users will get compilers errors (for instance, when referencing a view from a controller - missing symbol).
— Mirco
Mirco Dotta
Mar 28, 2015, 5:47:50 AM3/28/15
to Ben McCann, sbt...@googlegroups.com, play-fram...@googlegroups.com
(resending this as I was not subscribed to sbt-dev ML)
Mirco Dotta
Mar 29, 2015, 4:13:20 AM3/29/15
to Joshua Suereth, sbt...@googlegroups.com, play-fram...@googlegroups.com
Hey Josh,
On Saturday, March 28, 2015 at 12:40:56 PM UTC+1, Josh Suereth wrote:
Thanks so much for being open to this change.
Also, since this feature seems to be necessary only for properly setting up a project in IDEs, I'm thinking that maybe it should be a configurable thing, and the default may still be the current sbt behaviour (i.e., keeping all classfiles in the same place). If we do it this way, I assume it should be possible in sbteclipse to turn-on the switch allowing that src_managed sources are compiled to a separate output folder. Let me know what you think.
-- Mirco
On Saturday, March 28, 2015 at 12:40:56 PM UTC+1, Josh Suereth wrote:
I'd be ok with a classes_managed, but just a warning you may need to rework a lot of the packaging code in the default build to account for another base directory for classes.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "sbt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sbt-dev/ip86t7Biw_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CABY0rKN7-FSLS%2BQw%2BbmGv35pMVfjNvLn5smdtV8QBQ4ucUEu9g%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/24C9E33C-FF34-44D1-82A0-6F41EC24892B%40typesafe.com.--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
James RopR
Mar 29, 2015, 8:17:50 PM3/29/15
to Mirco Dotta, Joshua Suereth, sbt-dev, play-fram...@googlegroups.com
I think it makes more sense to keep only one classes directory in sbt, since there's only one classpath. Otherwise where would you stop, would it also make sense to have classes_java and classes_scala? Having only one classes directory makes things like byte code enhancement a lot more straight forward. It doesn't make sense anyway, all classes are managed by sbt, you never have an unmanaged classes like you do with sources.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
Ben McCann
Mar 30, 2015, 1:14:14 PM3/30/15
to sbt...@googlegroups.com, mirco...@typesafe.com, joshua....@typesafe.com, play-fram...@googlegroups.com
Yeah, sounds like it makes way more sense to focus on sbt-server than making any changes to SBT.
I'm curious to keep in mind how things will work with sbt-server as I make changes to sbteclipse and I think the way I was envisioning that sbt-server might work with Eclipse perhaps isn't exactly right. Does Gradle or any other build system have a client-server option available for Eclipe? Looking at what Gradle/Maven do has been a helpful guide to me in figuring out other Eclipse issues since a lot of the stuff in Eclipse doesn't seem to be documented.
Ben
On Monday, March 30, 2015 at 4:37:49 AM UTC-7, Josh Suereth wrote:
On Sun, Mar 29, 2015 at 8:17 PM, James RopR <ja...@typesafe.com> wrote:I think it makes more sense to keep only one classes directory in sbt, since there's only one classpath. Otherwise where would you stop, would it also make sense to have classes_java and classes_scala? Having only one classes directory makes things like byte code enhancement a lot more straight forward. It doesn't make sense anyway, all classes are managed by sbt, you never have an unmanaged classes like you do with sources.
Well..... theoretically you *could* have .class files generated by something "not java/scala". I understand what you're saying about simplyfying bytescode enhancers though.
classes_managed can quite easily be added by an sbt plugin that something like sbt-eclipse can depend on, it shouldn't be hard, by inspecting the Analysis object, to copy all the products of managedSources into a classes_managed directory, like play used to do. I think that would be a much better way of addressing this, rather than polluting what sbt currently does with an artificial distinction between classes that came from managed and unmanaged sources.
Option #2 (which Simon Schafer is working on) is to get sbt-server to the point that eclipse can just depend on it for the compilation aspect of building in the IDE, so that errors/etc come from sbt, and these classes should show up for the presentation compiler....We have a few PRs in to fix various IDE related thing in sbt-server, but longer term I hope that's the right fix.Short term, the plugin sounds like something that could be implmented FAR faster than changing sbt itself (our next minor release is ~2+ months away)
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscri...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to a topic in the Google Groups "sbt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sbt-dev/ip86t7Biw_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CABY0rKN7-FSLS%2BQw%2BbmGv35pMVfjNvLn5smdtV8QBQ4ucUEu9g%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscri...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/24C9E33C-FF34-44D1-82A0-6F41EC24892B%40typesafe.com.--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CABY0rKMDT3C%2B5%3Dzzr4mDNCQ%2Bs%2B8FxyYOTRzWGcedGBnP8h9iig%40mail.gmail.com.
Ben McCann
Mar 30, 2015, 2:44:36 PM3/30/15
to Joshua Suereth, sbt...@googlegroups.com, Mirco Dotta, play-fram...@googlegroups.com
The part I'm foggy about from the IDE side is what does the IDE configuration look like for such a setup. E.g. in Eclipse, I think that perhaps the .classpath, .project files, etc. don't really change, but we just tell Eclipse to use a different builder. I'm not entirely sure that's accurate though. I think it will be easier to figure this part out later.
I think that perhaps the nicest thing we could do for now is to move all the classes_managed code out of Play and into sbteclipse, so that folks can easily configure their Eclipse code and upgrade their Eclipse plugin independent of Play. All the IntelliJ settings were just removed from Play, so we're good on that front. I'm a little stuck on figuring out how to get classes_managed out of Play and into sbteclipse though because sbteclipse seems to have a strange usage of SBT keys that I don't quite understand. I filed a bug for the issue and am hoping that maybe I'll get lucky and someone will take it on before we release Play 2.4
On Mon, Mar 30, 2015 at 1:14 PM, Ben McCann <benjamin...@gmail.com> wrote:Yeah, sounds like it makes way more sense to focus on sbt-server than making any changes to SBT.I'm curious to keep in mind how things will work with sbt-server as I make changes to sbteclipse and I think the way I was envisioning that sbt-server might work with Eclipse perhaps isn't exactly right. Does Gradle or any other build system have a client-server option available for Eclipe? Looking at what Gradle/Maven do has been a helpful guide to me in figuring out other Eclipse issues since a lot of the stuff in Eclipse doesn't seem to be documented.
I believe Gradle has a server, but not sure it's used in eclipse.
If you're familiar with m2e, we'll be somewhat similar to that, only not embedded, but a client. The architecture should be similar of asking the sbt model for all the details and synchronizing with the eclipse model.The main difference between sbt-server integration work and m2e work is that activities of other clients may fire events to eclipse that it should respond to. e.g. When someone clicks "reload" on the browser for a play development application this may force a recompile, and eclipse should get notified this is happening and update its error markers appropriately. If we can synchronize "build state" in the server, we can get a nice unification of information from the various tools.In the distant future, clients may even have communication to each other. For example, when hitting reload on a play development application, the user may want to *avoid* having this rebuild, but control rebuilds by the IDE build button. These types of interactions should be possible to script/design/plan once we have the server integrated in all the things.- Josh
Ben McCann
Mar 30, 2015, 2:57:34 PM3/30/15
to Joshua Suereth, sbt...@googlegroups.com, Mirco Dotta, play-fram...@googlegroups.com
Great, thank Josh. I'll ping you directly.
Yeah, the only place I have the classes_managed bug right now is the link below. Let me know if there's anywhere else you'd like me to file it.
Thanks,
Ben
On Mon, Mar 30, 2015 at 2:44 PM, Ben McCann <b...@benmccann.com> wrote:The part I'm foggy about from the IDE side is what does the IDE configuration look like for such a setup. E.g. in Eclipse, I think that perhaps the .classpath, .project files, etc. don't really change, but we just tell Eclipse to use a different builder. I'm not entirely sure that's accurate though. I think it will be easier to figure this part out later.
Yeah, there's two alternatives in eclipse:1. the .project file should have the "flavor" or "nature" for SBT2. The .classpath should probably reference a container of some sort, so the sbt-server can control what shows up in there, and update it when users alter the build.
3. There will be an sbt-specific builder to actually perform compilation for the proiject. That would have to be tunable.I agree with you on classes_managed. Is the bug you filed our only tracking here? Why you don't you ping me individually, and we can do a google hangout to walkthrough the change and make sure it gets through.- Josh
James RopR
Mar 30, 2015, 6:49:40 PM3/30/15
to Ben McCann, Joshua Suereth, sbt-dev, Mirco Dotta, play-fram...@googlegroups.com
Obviously sbt-server is a long term solution to this, but for Play 2.4, we probably need to solve it now.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
James RopR
Mar 30, 2015, 7:00:39 PM3/30/15
to Joshua Suereth, Ben McCann, sbt-dev, Mirco Dotta, play-fram...@googlegroups.com
I think IntelliJ does have the same problem, but installing the IntelliJ Scala plugin is incredibly simple in IntelliJ (one click), whereas installing the Scala plugin in Eclipse requires many steps (add update site, get list of plugins, click random things that you're not sure if you need or not, blah blah blah.... I want to break something every time I have to install an Eclipse plugin.... urgh....)
On 31 March 2015 at 09:52, Joshua Suereth <joshua....@typesafe.com> wrote:
I think Ben + I will try to work on getting this into sbteclipse directly. Intellij (i think) doesn't suffer the same issue (someone correct me if I'm wrong). If you do have time to get around it to it (not wed, of course), then please try to get it into sbteclipse.
Ben McCann
Mar 30, 2015, 7:33:11 PM3/30/15
to sbt...@googlegroups.com, Joshua Suereth, Mirco Dotta, play-fram...@googlegroups.com
One of the main reasons we were adding classes_managed for Eclipse in Play is that many Java users don't have ScalaIDE installed and complain about having to do that to write a Java Play app. Play generates Scala code for its routes and templates into src_managed. If we add src_managed to the classpath, then Eclipse doesn't do anything with the Scala sources (the Java sources work just fine) since Eclipse only handles Java by default. So the classes_managed workaround allows things to work pretty well for users without Scala IDE. That's why a lot of mention of this involves whether the user is primarily Java or Scala.
We'd only done this for Eclipse in Play. It seems that IntelliJ users are happier with installing IntelliJ's scala support. Which I guess makes sense given the description James gave of relative difficulty of installing a plugin in the two IDEs.
If multiple plugins were going to want this, then I suppose it could make sense to live in a separate plugin. But then the common classes_manged plugin would need to be released and the eclipse plugin would need to depend on that one, right? Whether we want this to go into sbteclipse or a separate plugin that sbteclipse will then depend on, I think it'd be helpful to merge this PR first, which I created in anticipation of adding a classes_managed option to sbteclipse.
If you guys want to take a stab at this without me, I won't complain ;-) I'm stretched a bit thin and am not sure I'd be much help. Most of the code already exists here, and I'm hoping someone a bit more familiar with sbt/scala will be able to get it wired up a lot faster. That being said, I'd like to see this make it's way in before Play 2.4 and am still more than happy to participate.
Thanks for all the help with this guys!
-Ben
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CABY0rKPQiRCPV-mG%3Dn8rCDdKcqywmgr70gyuOXR%3DvJHOiWvLrg%40mail.gmail.com.
Ben McCann
Mar 30, 2015, 9:34:53 PM3/30/15
to sbt...@googlegroups.com, Mirco Dotta, play-fram...@googlegroups.com
I did give you keys to merge/review others PRs, based on what Iv'e seen contribution wise from you
Thanks! FYI, I can for quite a few repos, but I don't seem to have merge permissions on sbteclipse.
yeah, let's sync up on what your major issues are in sbt space via quick hangout and we'll see what we can do.
I think I've mostly figured out the basics of SBT these days, but sbteclipse does weird stuff. It took me forever to even figure out where half the functions were coming from, which I just sent a PR to fix. That helps a lot, but it's still doing some stuff that looks pretty weird to me. It's extracting the project structure from some state variable to find and then returning that wrapped in a scalaz object in order to set the default value of a setting. It's definitely not idiomatic SBT :-p
On Mon, Mar 30, 2015 at 7:33 PM, Ben McCann <b...@benmccann.com> wrote:One of the main reasons we were adding classes_managed for Eclipse in Play is that many Java users don't have ScalaIDE installed and complain about having to do that to write a Java Play app. Play generates Scala code for its routes and templates into src_managed. If we add src_managed to the classpath, then Eclipse doesn't do anything with the Scala sources (the Java sources work just fine) since Eclipse only handles Java by default. So the classes_managed workaround allows things to work pretty well for users without Scala IDE. That's why a lot of mention of this involves whether the user is primarily Java or Scala.
The next issue is the eclipse command takes forever to run. Are java users runing "~ run" while eclipse is going on? If so, they'll randomnly face the concurrent compile race explosion issue that helped lead to writing sbt-server to begin with...
We'd only done this for Eclipse in Play. It seems that IntelliJ users are happier with installing IntelliJ's scala support. Which I guess makes sense given the description James gave of relative difficulty of installing a plugin in the two IDEs.If multiple plugins were going to want this, then I suppose it could make sense to live in a separate plugin. But then the common classes_manged plugin would need to be released and the eclipse plugin would need to depend on that one, right? Whether we want this to go into sbteclipse or a separate plugin that sbteclipse will then depend on, I think it'd be helpful to merge this PR first, which I created in anticipation of adding a classes_managed option to sbteclipse.
If you use autoplugins, you can basically have eclipse depend on this, and each will auto-inject into relevant builds. I've just reviewed all your sbteclipse PRs, take a look. Let's chat more on a hangout (I did give you keys to merge/review others PRs, based on what Iv'e seen contribution wise from you).
If you guys want to take a stab at this without me, I won't complain ;-) I'm stretched a bit thin and am not sure I'd be much help. Most of the code already exists here, and I'm hoping someone a bit more familiar with sbt/scala will be able to get it wired up a lot faster. That being said, I'd like to see this make it's way in before Play 2.4 and am still more than happy to participate.
yeah, let's sync up on what your major issues are in sbt space via quick hangout and we'll see what we can do.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAP_KTWYVYJbeMdrMK68mfvh67zOSSfXE432wYA_opNaRcbxpKQ%40mail.gmail.com.
Ben McCann
Mar 31, 2015, 10:51:57 AM3/31/15
to sbt...@googlegroups.com, Mirco Dotta, play-fram...@googlegroups.com
DOH, forgot that plugin is on typesafehub, not sbt group. Fixed.
Seems it still didn't work :-)
On Mon, Mar 30, 2015 at 9:34 PM, Ben McCann <b...@benmccann.com> wrote:I did give you keys to merge/review others PRs, based on what Iv'e seen contribution wise from youThanks! FYI, I can for quite a few repos, but I don't seem to have merge permissions on sbteclipse.
DOH, forgot that plugin is on typesafehub, not sbt group. Fixed.
yeah, let's sync up on what your major issues are in sbt space via quick hangout and we'll see what we can do.I think I've mostly figured out the basics of SBT these days, but sbteclipse does weird stuff. It took me forever to even figure out where half the functions were coming from, which I just sent a PR to fix. That helps a lot, but it's still doing some stuff that looks pretty weird to me. It's extracting the project structure from some state variable to find and then returning that wrapped in a scalaz object in order to set the default value of a setting. It's definitely not idiomatic SBT :-p
Yep. To be fair, I think Scalaz API on sbt state would clean that APi up dramatically for commands, but mostly we don't want people using commands, as it's too easy to get things wrong or start relying on internal APIs we want to clean up. The sbteclipe code base is clean, but foreign compared to most other plugins right now. Thanks for all the work you do to improve thins.- Josh
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAH3cagM_HkQWNdJdFr8Go7MAXt3fPFkBLHD4HDsuT813cK3gZw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "sbt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sbt-dev/ip86t7Biw_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAP_KTWbo9pmwEd%3DndbkCkaVBYnQcH%3DF86v7V8X0fgHoJx2_oxg%40mail.gmail.com.
Ben McCann
Mar 31, 2015, 11:06:48 AM3/31/15
to sbt...@googlegroups.com, Mirco Dotta, play-fram...@googlegroups.com
Yep. Thanks! I hadn't gotten through that much of my inbox this morning yet :-)
I'll leave the pending PRs for you to merge since you've been reviewing them unless they look okay to you and you want me to hit merge on them.
Thanks,
Ben
On Tue, Mar 31, 2015 at 7:54 AM, Joshua Suereth <joshua....@typesafe.com> wrote:
You should have a github invite.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAH3cagNum49emsnWfdXs_5hJPsJLNA4xqRnYTVrf4oy3Y1mcag%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "sbt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sbt-dev/ip86t7Biw_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAP_KTWbDCM8jyG60jS%2BpCqF_E76-xD6zR%3D39cxZe2g_pGCMKvQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages