Move the collectionContrib project to a collection-contrib subdirectory

[julienrf]

This is a tentative to address #51

At least now, the package task builds a .jar file that contains .class files. The publishLocal task, however, still does not build a .jar file containing the .class files.

I’ve noticed that collectionContribJS/publishLocal builds a correct .jar file. The only difference between the JS and JVM projects is that the JVM project applies the scalaModuleSettingsJVM settings, which does something with sbt-osgi, which I didn’t dig into…

[julienrf]

Also, I’ve noticed that the directory layout of the generated artifact is unusual: it doesn’t contain a jars directory. Instead, there is a bundle directory (that contains this .jar file where the .class files are missing). I’m not sure whether this is expected or not.

[SethTisue]

(haven't gotten to this yet, but haven't forgotten about it)

[mpollmeier]

Doesn't look like this fixes the publishing issue. The two jars published by publishLocal still only contain metadata.

Note however that package creates three jars:

• target/scala-2.13/scala-collection-contrib_2.13-....jar which only contains metadata (that's what's being published)
• .jvm/target/scala-2.13/scala-collection-contrib_2.13-....jar which looks correct
• .js/target/scala-2.13/scala-collection-contrib_sjs....jar which.

Maybe this helps in getting to the bottom of it.

[julienrf]

Since this is involving sbt-crossproject, I’m pinging @sjrd, maybe the cause of the problem is obvious to him. See also the issue discussion in #51.

[sjrd]

I think you're simply publishing the implicit root project instead of (or more likely in addition to) the collectionContrib and collectionContribJS subprojects. One of the great caveats of aggregation in sbt, and in particular of aggregation in the root project.

You shouldn't use a naked publishSigned, but rather individually invoke collectionContrib/publishSigned and collectionContrib/publishSigned.

This doesn't have a direct relationship to sbt-crossproject, but of course due to how sbt-crossproject works, you end up with an implicit root project that you would otherwise not have.

I'll conclude by saying that the changes in this PR are not necessary nor helping. It is purely a matter of what commands are invoked when publishing.

[julienrf]

We do scope the publish command to a specific project:

scala-collection-contrib/build.sh

Line 36 in c7bcc3b

projectPrefix="collectionContribJS"

[SethTisue]

the changes in this PR are not necessary nor helping

that's how it looks to me as well. I think this an sbt-osgi thing, most likely. I'm closing the PR and looking into other fixes for #51

[julienrf]

This seems to fix #64.

[SethTisue]

hmm, interesting. I'll take another look

[SethTisue]

I poked at this for an hour or so just now. I was able to reproduce #64, and I also saw that this PR fixes #64 in the narrow sense that the JUnit tests don't have red squigglies. But it also didn't get me a fully functioning project in IntelliJ. I'm not able to run the tests, or even jump-to-definition from src/test to src/main.

So I'm a bit reluctant to merge this PR since it sort of fixes things and sort of doesn't, and adds an extra level of directories that seems like it should be unnecessary, and that we don't have in other cross-built Scala modules such as scala-parser-combinators.

But I feel that I've poked at this long enough now, and I didn't reach any firm conclusions, so I won't stand in the way if you want to merge this, Julien. But I'm curious whether this PR actually makes you able to compile and run the tests? I'm not sure it's worth merging this unless it gets at least some of us to where IntelliJ works as it should.

[julienrf]

@SethTisue Thanks for your time! I don’t remember if I could run the tests from within IntelliJ, I probably didn’t test that. I would say that anyway the problem is on IntelliJ side. Let’s not spend more time on it.