The issue is fixed.
Here's an explanation which interested people can read through:
For the earlier mail, the default resourceDirectory =>
core/src/main/resources didn't yield the expected result. By default all
the static resources placed under this directory are picked up and included
in the ja
Ah, I think I see the issue. resourceManaged and core/src/resources
aren't included in the classpath; to achieve that, you need to scope
the setting to either "compile" or "test" (probably compile in your
case). So, the simplest way to add the extra settings would be
something like:
resourceGenera
Based on the conversation on PR, the intent was not to pollute the source
directory and hence we are placing the generated file outside it in the
target/extra-resources directory. I agree that the "sbt way" is to add the
generated resources under the resourceManaged setting which was essentially
th
To echo my comment on the PR: I think the "sbt way" to add extra,
generated resources to the classpath is by adding a new task to the
`resourceGenerators` setting. Also, the task should output any files
into the directory specified by the `resourceManaged` setting. See
http://www.scala-sbt.org/0.13
Perhaps you need to make the "compile" task of the appropriate module
depend on the task that generates the resource file?
Sorry but my knowledge of sbt doesn't really go too far.
On Tue, May 17, 2016 at 11:58 AM, dhruve ashar wrote:
> We are trying to pick the spark version automatically from p
We are trying to pick the spark version automatically from pom instead of
manually modifying the files. This also includes richer pieces of
information like last commit, version, user who built the code etc to
better identify the framework running.
The setup is as follows :
- A shell script genera
