Split code into multiple artefacts

[backuitist]

Currently all the matchete code lives in a single jar with a few optional dependencies.
In order to have a lighter matchete we'd like to split this code in the following artefact:

• matchete-core: no dependencies (a good candidate for scala.js).
• matchete-junit
• matchete-json
• matchete-xml

[backuitist]

I'm quite new to scala.js, but I'm planning to test matchete-core with JUnit. Is this a problem for cross-publishing to scala.js?

[sLite]

As discussed by mail i'm happy to help out bringing matchete to scala.js :)

I'm also quite new to scala.js, but as far as my research goes, JUnit could only be used to test the version compiled for the JVM.
As JUnit doesn't cross-compile to javascript (and probably never will, as it's source is java, not scala), testing the javascript version isn't possible with it.

The tests for the javascript artifacts have to run within a JS environment (Rhino or node.js) to ensure that the output of the scalajs-compiler does what it should. Thus the tests need to be written for a testing framework that can compile to javascript itself.

So either all the tests need to be ported to a testing framework that plays well with scala.js or we would need different testsuites for both versions.

[backuitist]

Ok, thanks for the explanations, that makes sense. Maybe an option for cross testing would be to develop a small scala.js junit runner. It shouldn't be too hard as matchete only use @Test annotations. What do you think?

[sLite]

Somehow i don't like the idea to make a pseudo junit runner that implements org.junit classes, which it would have to for the imports to resolve...

[backuitist]

I may have missed something, but it seems to me that the only thing you need to have is an @Test annotation. I believe you could easily implement a uTest runner that is aware of that annotation.

Now if you're willing to move the tests from JUnit to uTest, that is fine by me, I'll accept a pull request :)

[sLite]

Yea, but the @test annotation still needs an import.

import org.junit.Test

Which is not resolvable by the scalajs-compiler when compiling the tests because there is no JUnit for scala.js

I'll give it a try today evening, starting from your new branch. :)

[backuitist]

Great!

Back to JUnit, just for the record, you can easily add (manually) that one annotation in your source code without having to drag the whole of junit.

[sLite]

Update from my side.

I ported all tests to utest and they pass on the JVM, which is nice.

But trying to run them on JS fails horribly. Digging into the source of the matchers, there is actually a lot of of reflection magic going on which is not supported by scala.js.

I will have a deeper look into this in the next days when i got some time at hand, but i doubt it's possible to bring matchete to scala.js with all the features it currently has.
As it looks now, it would even be necessary to break existing matchers, because things like beA are probably not going to work for cross-compilation any time soon.

[backuitist]

Right. I guess we should split the core further and move reflection based matchers to another module: core-reflect, which junit would depend on.
Thanks for your work!

[sLite]

I'm going finish my work on the utest migration and push that to github so you can take a look at it check if you feel fine with the change from JUnit to utest.

I'm going to start the separation of reflection based stuff after that. But i fear that there is some stuff that needs to be rewritten for the new core, because as far as i monitored yesterday, some very basic matchers (f.ex. beEqual for numbers) also use reflection through Diffable.

So this is probably going to take a while.

[backuitist]

Perfect. I'll take a look.
Diffable is a type class that is mostly implemented by implicit macros. As far as I know macros are a viable option for scala.js.

[sLite]

Yea, macros should work fine.
I guess the whole thing shouldn't take me more than a few days, depending on how much time i can spare :)

[backuitist]

Based on your utest migration I can do the reflection split if you want :)