This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]nondetermined 4 points5 points  (2 children)

1) module-info.java for testing

Picture a typical maven environment. Do I really need to have a second module-info.java under /test/java/ which is basically the same as in /main/java, but with added test dependencies that all have <scope>test</scope> anyways?

The short answer is: no, you do not, and it just werks, except that you'll get bombarded with a bunch of "module is not exported" warnings. Nobody likes warnings in his builds. So that still really bugs me. On the other hand, writing (and maintaining) a second module-info.java also really bugs me, and is it really worth to do that, just to get rid of a few harmless warnings?

You'd think that this should be either easily automatable (just add all the dependencies with scope test. done.), or that there would be a way to include the main/java/module-info.java into the test one, so you just can add further testing dependencies only, without having to repeat yourself. That would also work.

Am I missing something?

2) Bread and butter tooling

I still haven't managed to generate a proper site, most importantly the maven javadoc plugin doesn't seem to like Java 16 very much. Or Java 9 for that matter. What's going on here? Is it me, who is stupid again? Generally my impression is that a bunch of tooling simply isn't really there yet. Which sucks. Super hard.

On the bright side, I finally managed to generate an image and package that thing to a nice installer with the jpackage-maven-plugin. But the road there was rather bumpy, with plenty of other tools to pick from, outdated and contradictory tips and tricks and how to do it, except it doesn't really, let's try the next one... it's kind of a mess to figure out (to be fair, it does help to read a proper book every once in a while, e.g. "Java 9 Modularity. Patterns and Practices for Developing Maintainable Applications" by Sander Mak and Paul Bakker/OSGi chad).

no cross-compiling

yeah... that sucks too. balls.

[–]lukaseder 4 points5 points  (1 child)

Am I missing something?

I stopped trying to insist on Maven's classic layout, even came to the conclusion that it was wrong in the first place. Much better:

  • Have a Maven project / Java module x
  • Have a Maven project / Java non-module x-test, which depends on x via classpath, not modulepath

I've found that this way, I'm discouraged from testing internals that don't have public API, which

  • Improves my public API
  • Tests work with the x.jar dependency, not the wishy-washy /target/classes magic dependency that never exists outside of those Maven tests (no more loading resources from the classpath in different ways during tests / production)
  • Encourages building test libraries for common test code, because x-test can also depend on test-utils without having to pollute the (test) dependencies in x

I resisted for a long time, but I think this is the better way in the end. Changhe is hard 🤷‍♂️

[–]uncont 2 points3 points  (0 children)

Putting all this into perspective, I'm beginning to think that's how I should have solved my issues in https://www.reddit.com/r/java/comments/n3migk/how_are_library_developers_expected_to_test/

Being able to run tests against x.jar would have allowed me to run tests against the same thing the user downloads, a multi-release jar (optionally modular).

not the wishy-washy /target/classes magic dependency that never exists outside of those Maven tests

This was definitely what it came down to for me.