softprops / coffeescripted-sbt

pour some coffee for scala
MIT License
55 stars 5 forks source link

src/test/coffee is ignored #14

Closed yatesco closed 11 years ago

yatesco commented 11 years ago

Please see https://github.com/yatesco/sbt-coffeescripted-no-test-compilation for a skeleton sbt project demonstrating the problem

softprops commented 11 years ago

@yatesco I finally got a chance to check this out. I can't seem to reproduce it in your repo. Here is a gist with some debug output https://gist.github.com/4432104. I also made a scripted test (linked in this issue) which verifies code under test gets compiled in test:compile, just like sbt does with scala sources when executing test:compile. Can you verify you are compiling under the test config. If you are only compiling under the main config, test sources will not get compiled, for both coffee and scala and other languages. If you can confirm, I'd like to close this issue out.

yatesco commented 11 years ago

You are right - it was a rookie mistake - apologies and please close it.

On a related note - how do you handle the generated javascript? How would you reference this compiled javascript in a Jasmine test set for example?

softprops commented 11 years ago

no worries. I didn't actually have a test before this before and now I do :+1:

I use this mostly in conjunction with web apps so my view is mainly that the sources are "sources" but the generated artifacts are "resources". In sbt and mvn type projects you will find the differences under src/main/blah vs src/resources/blah.

From a source that requires the resource you can reference it from the class path, sbt set resource references in your cp for you.

So if you have some object Foo, you can say Foo.getClass().getResource("/path/to/resource")

If the path starts with a slash, its relative to the root of your resources directory. If not, its relative to the package your class or object is in.

An example is in this g8 project https://github.com/softprops/coffee-filter.g8/blob/master/src/main/g8/src/main/scala/Server.scala#L9 https://github.com/softprops/coffee-filter.g8/blob/master/src/main/g8/src/main/scala/Page.scala#L10. Here, I'm setting a lookup path for serving static resources (like generated javascript). These get aliased to "assets" so I can reference them from /assets/js/foo.js ect https://github.com/softprops/coffee-filter.g8/blob/master/src/main/g8/src/main/scala/Page.scala#L25

yatesco commented 11 years ago

Thanks for the info. I understood the difference between sources and resources, my question was more specifically what do you do with the generated test javascript, which end up in target/...?

On 2 January 2013 14:55, doug tangren notifications@github.com wrote:

no worries. I didn't actually have a test before this before and now I do [image: :+1:]

I use this mostly in conjunction with web apps so my view is mainly that the sources are "sources" but the generated artifacts are "resources". In sbt and mvn type projects you will find the differences under src/main/blah vs src/resources/blah.

From a source that requires the resource you can reference it from the class path, sbt set resource references in your cp for you.

So if you have some object Foo, you can say Foo.getClass().getResource("/path/to/resource")

If the path starts with a slash, its relative to the root of your resources directory. If not, its relative to the package your class or object is in.

An example is in this g8 project https://github.com/softprops/coffee-filter.g8/blob/master/src/main/g8/src/main/scala/Server.scala#L9 https://github.com/softprops/coffee-filter.g8/blob/master/src/main/g8/src/main/scala/Page.scala#L10. Here, I'm setting a lookup path for serving static resources (like generated javascript). These get aliased to "assets" so I can reference them from /assets/js/foo.js ect https://github.com/softprops/coffee-filter.g8/blob/master/src/main/g8/src/main/scala/Page.scala#L25

— Reply to this email directly or view it on GitHubhttps://github.com/softprops/coffeescripted-sbt/issues/14#issuecomment-11810431.

softprops commented 11 years ago

I've never really had the use case. In scala your test/scala are usually specs and tests that include the main cp for references to your source code. From the jvm, you should be able to reference them the same way as resources with TestFoo.getClass().getResource("/path/inside/test.js")

yatesco commented 11 years ago

OK - ta. Happy new year!

On 2 January 2013 15:34, doug tangren notifications@github.com wrote:

I've never really had the use case. In scala your test/scala are usually specs and tests that include the main cp for references to your source code. From the jvm, you should be able to reference them the same way as resources with TestFoo.getClass().getResource("/path/inside/test.js")

— Reply to this email directly or view it on GitHubhttps://github.com/softprops/coffeescripted-sbt/issues/14#issuecomment-11811783.

softprops commented 11 years ago

you too man!