sbt-xjc plugin commandeers all of src_managed?

[FranklinChen]

sbt-xjc appears to claim all generated files, resulting in SBT getting confused by the double-counting since another plugin (sbt-antlr) has claimed its generated files already. Sample failing project here for you to verify. Log excerpt:

$ sbt compile
...
[error] ...test-antlr4-jaxb/target/scala-2.11/src_managed/main/antlr4/com/franklinchen/antlr4/ExprBaseListener.java:16: ExprBaseListener is already defined as object ExprBaseListener
[error] public class ExprBaseListener implements ExprListener {
[error]              ^

[FranklinChen]

Any word on this? It's a show-stopper for me, so I will try to debug and fix it myself if you don't have the time right now.

[retronym]

I think this is a regression since: 226ff93

You should be able to workaround by adding with sourceManaged in xjc in Compile ~= (_ / "xjc") to your project's settings.

Perhaps @benmccann could comment on the motivation for that commit.

[benmccann]

src_managed/main/xjc was not recognized as a source directory by Eclipse, but src_managed/main was, so that change make the tool work in Eclipse.

Can we make this work without adding a sub-directory that's not on the classpath? I notice that the sbt-antlr4 plugin referenced above doesn't use a subdirectory either, but @FranklinChen you seem to think the problem is only with this plugin?

[FranklinChen]

@retronym Thanks, that worked! Maybe it should be documented.

@benmccann The sbt-antlr4 plugin caused problems too, but I worked around it with forcing its own subdirectory with

javaSource in Antlr4 := (javaSource in Antlr4).value / "antlr4"

[retronym]

An alternative would be to change the default to create a src_managed_xjc directory, and add that to the list in the SBT setting: managedSourceDirectories.

The eclipse SBT plugin does something with this, although it looks like a bit of a kludge:

https://github.com/typesafehub/sbteclipse/blob/ea8e22034c06a260a3a418bc57aee6a5cc3249ac/src/main/scala/com/typesafe/sbteclipse/core/EclipsePlugin.scala#L95-L112

I think it is better handled in IntelliJ, as the project model can natively handle multiple source generated source directories: https://github.com/JetBrains/sbt-structure/blob/1aecec04837451113be5a74e57d39f1e81ad7f49/extractor/src/main/scala/org/jetbrains/sbt/extractors/ProjectExtractor.scala#L45-L51

[theBlackDragon]

Judging by the SBT documentation the correct directory to use would be "src_managed/xjc". It seems to me that deviating from this convention would be inadvisable.

[theBlackDragon]

OK, I did some more digging and judging from what I see "src_managed/main/xjc" seems to actually be the expected output location (so the problem would be in Eclipse, IntelliJ had a similar issue btw), however the Sbt documentation is so vague in this respect that pretty much every sbt plugin project has tripped over this exact problem at some point (see here and here for example).

I suspect the "main" here is the name of the subproject (which there aren't so the default is used), I'm not entirely sure where in the Sbt code this is added though, but Default.nameForSrc(config: Config) seems like the only plausible candidate.

[eed3si9n]

See sbt/sbt-buildinfo#14. I think target/scala-2.10/src_managed/main/sbt-buildinfo is a good convention to avoid naming conflict. If someone wants to clarify that in https://github.com/sbt/website/blob/master/src/reference/04-Howto/03-Howto-Generating-Files.md we welcome pull requests.

[theBlackDragon]

@eed3si9n why not add a "main" subfolder to "src_managed" by default? From what I've been able to find out this folder is only added "automagically" when inConfig() is used, so theoretically (if following the recommendations in the documentation, which you'd only know if you've read and understood the "Best practices" section) it should always be present for plugins generating code, however my experience is that a lot of plugins don't actually use it (probably out of ignorance, since it's not mentioned at all in chapter on generating files).

Note also that inside the source generation task sourceManaged is "$stuff/src_managed/main" (when using inConfig()), however if I inspect the value of "sourceManaged" for this task from sbt it's "$stuff/src_managed", this is confusing, to say the least.

Maybe this discussion is more suited for sbt/sbt#1664 but I'm confused so I can't tell for certain.

[eed3si9n]

@theBlackDragon

why not add a "main" subfolder to "src_managed" by default?

Isn't it already being added?

Foo> compile:sourceManaged
[info] /Users/xxx/foo/target/scala-2.10/src_managed/main

A plugin may offer a configuration-neautral task such as obfuscate that could work as compile:obfuscate or test:obfuscate. The documentation also scopes the sourceManaged to Compile:

sourceGenerators in Compile += Def.task {
  makeSomeSources((sourceManaged in Compile).value / "demo")
}.taskValue

[theBlackDragon]

I'd like to dig this up again (and apologies for letting this linger for so long).

As remarked in the sbt/sbt#1664 (and earlier in the thread by @eed3si9n) the suggested way to do this for Sbt is by having the generated source under a subdirectory of sourceManaged.

Not adhering to this actually breaks the build in IDEA if other source generating plugins are present who do follow this convention (we encountered this issue by combining sbt-xjc with sbt-cxf-wsdl2java in a project, for example).

If this is still an issue for Eclipse projects then imho either the eclipse plugin needs to be updated to be aware of this convention or an issue needs to be raised with Sbt arguing against adding the "main" part to sourceManaged.

Either way I would suggest reverting 226ff93 . WDYT?

[benmccann]

I added documentation for sbteclipse's classes managed feature that @retronym referred to as a kludge so that it's more obvious what it's trying to do.

[benmccann]

It sounds like the latest suggestion for this problem is not to use the managed sources directory at all. See sbt/sbt#1664

[benmccann]

I just fixed this. It only took me a few years :-)