I thought that files in src_managed always get compiled to classes_managed?
I have:
./src/sbt-test/sbt-xjc/xero/target/scala-2.10/src_managed/main/com/sbt/generated/Account.java
And it's getting compiled to:
./src/sbt-test/sbt-xjc/xero/target/scala-2.10/classes/com/sbt/generated/Account.class
Can this be a bug in setting up sourceGenerators? The source code is here: https://github.com/sbt/sbt-xjc/blob/master/src/main/scala/com/github/retronym/sbtxjc/SbtXjcPlugin.scala
Thanks,
Ben
I thought that files in src_managed always get compiled to classes_managed?
--
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.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CABY0rKN7-FSLS%2BQw%2BbmGv35pMVfjNvLn5smdtV8QBQ4ucUEu9g%40mail.gmail.com.
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.
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.
On Sat, Mar 28, 2015 at 5:47 AM, Mirco Dotta <mirco...@typesafe.com> wrote:
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.
Hey Josh,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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/5BA98F75-D269-499E-8709-29620BE73D11%40typesafe.com.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CABY0rKMDT3C%2B5%3Dzzr4mDNCQ%2Bs%2B8FxyYOTRzWGcedGBnP8h9iig%40mail.gmail.com.
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.
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
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.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CABY0rKPQiRCPV-mG%3Dn8rCDdKcqywmgr70gyuOXR%3DvJHOiWvLrg%40mail.gmail.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.
I did give you keys to merge/review others PRs, based on what Iv'e seen contribution wise from you
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.
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.
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
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAH3cagM_HkQWNdJdFr8Go7MAXt3fPFkBLHD4HDsuT813cK3gZw%40mail.gmail.com.
DOH, forgot that plugin is on typesafehub, not sbt group. Fixed.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAP_KTWbo9pmwEd%3DndbkCkaVBYnQcH%3DF86v7V8X0fgHoJx2_oxg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/CAH3cagNum49emsnWfdXs_5hJPsJLNA4xqRnYTVrf4oy3Y1mcag%40mail.gmail.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.