Packaging multi-project applications?

[TomasMikula]

Is it possible to package a multi-project application?

My build.sbt starts like this

lazy val root = project.in(file(".")).dependsOn(foo, bar)

lazy val foo = project in file("foo")

lazy val bar = project in file("bar")

When I package the root project using sbt package-javafx, JAR files of the nested projects are not included in the bundle.

[metasim]

I'm having this problem too. @TomasMikula did you find any workaround? I have my JavaFX code in one of the sub projects and am trying to pull in sibling project. When I do a inspect packageJavafx it shows as a dependency foo/runtime:fullClasspath. When you inspect that, it shows the compilation target directories for the other module in there. Line 150 of the plugin shows that the task pulls in fullClasspath in Runtime, but only selects jar files for inclusion (line 188).

Looking into hacking up my package task for the javafx sub-project to include stuff in the runtime classpath, or somehow leveraging the assembly plugin. But I'm hitting the edge of my SBT skills, so I'm interested if you found an easier solution.

[metasim]

I think I have a partial work around, which is to set exportJars := true in all of your modules. That might have other implications, but it at least keeps the plugin from filtering out the non-JAR components of the classpath.

[metasim]

Correction!

Don't set exportJars:= true in all of your modules! The generated app won't run (at least not on MacOS)! Do it in all of them except the one doing the packaging. So, inn your example, I suspect you'd want to set exportJars:=true in foo and bar, but not root.

[TomasMikula]

Hi Simeon, I resorted to splitting my application into separate sbt projects and have the subprojects as normal JAR dependencies of the main project.

[Maatary]

Hi Metasim,
Hi,

I was wondering if you could share some though on a fix you did on sbt-fx.

I was wondering why do you call your workaround a "partial workaround". That is, what is your overall understanding of the problem since then? I simply would appreciate if you could share your conclusions on using your workaround, if you see some limitation to it. Most importantly if exportJars:=true has cause some other issue, implication, slowdown and etc...

Many thanks for your understanding,

Maat

[acapo-actioip]

I'm sorry, but I haven't looked at this yet. If Simeon's solution works, it might not be necessary to do anything with the plugin.

[Maatary]

Hi acapo,

I would like to know what is the implication of using exportjar:=true in the overall compilation process ? I mean I know that it packages thing but is that all in terms of consequences?

[metasim]

Hmmm... trying to remember.... I think I considered it a partial fix because a) it requires the non-packaging module to build the jar for integration with other modules, even if you're not building packaging (e.g. just running tests), and 2) I think the correct solution would be for the plugin to more deeply analyze the SBT dependency tree and convert high-level module dependencies into either a synthesized artifact combining and packaging them all (meh) or depending on the package task output from those modules instead. That said, it's been a while and my memory is fuzzy, so take this with a grain of salt.

[Maatary]

Ok git,

Just for the record, did you keep on using it, you resorted in splitting
your project, or you drop the all thing. And if you kept on using it as by
your workaround, so far so good?

Many thanks,

M

On Wed, Aug 13, 2014 at 3:23 PM, Simeon H.K. Fitch <notifications@github.com

wrote:

Hmmm... trying to remember.... I think I considered it a partial fix
because a) it requires the non-packaging module to build the jar for
integration with other modules, even if you're not building packaging (e.g.
just running tests), and 2) I think the correct solution would be for the
plugin to more deeply analyze the SBT dependency tree and convert
high-level module dependencies into either a synthesized artifact combining
and packaging them all (meh) or depending on the package task output from
those modules instead. That said, it's been a while and my memory is fuzzy,
so take this with a grain of salt.

—
Reply to this email directly or view it on GitHub
#12 (comment).

[guilgaly]

Since I had the same issue, I have implemented a possible fix here: https://github.com/guilgaly/sbt-javafx/tree/internal-dependencies-fix

What I do is that I add a fx:fileset in fx:jar for each element in the project's internalDependencyClasspath. So all files which are added to the classpath from other sub-projects get packaged in the jar, just like the files from the main project itself. It seems reasonable to me - but then, I'm entirely new to both SBT plugins and JavaFX application packaging, so... Do you see any drawback to this solution?

If it seems fine, I'll submit a pull request.