Failure when using flat package structure (my.package.name instead of my/package/name)

[smola]

I used to have the following source directory: src/main/java/io.mola.galimatias. This made coveralls unable to find sources:

[ERROR] Failed to execute goal org.eluder.coveralls:coveralls-maven-plugin:2.1.0:cobertura (default-cli) on project galimatias: Build error: Could not find source file io/mola/galimatias/Domain.java from any source directory -> [Help 1]

Changing to src/main/java/io/mola/galimatias fixed the problem.

Failure: https://travis-ci.org/smola/galimatias/jobs/16153713

Successful build after changing the directory structure: https://travis-ci.org/smola/galimatias/jobs/16154263

It seems the former directory structure is increasingly common, but I'm not sure how much "standard" it is...

[trautonen]

I guess it's valid to use flat package directories, and in Scala its pretty usual I guess. I have some doubt though how the flat hierarchy is implemented most often. Do you have all the packages flatten in unique directories or is the hierarchy broken at some level?

Is this the "valid" way to do it?

io.mola.galimatias.util/Util.java
io.mola.galimatias.service/MyService.java
io.moal.galimatias.service.helper/MyServiceHelper.java

If that's the case, then it's pretty straightforward to implement to the coveralls plugin. But if something does nested flat hierarchies, it's another story.

io.mola.galimatias/util/Util.java
io.mola.galimatias/service/MyService.java
io.moal.galimatias/service.helper/MyServiceHelper.java

For the later it's quite impossible to make any reasonable solution.

@smola do you have any idea if the first suggestion is more valid and could be implemented?

[trautonen]

Closing this issue as won't fix. Flat package naming is not generally a good idea and this issue hasn't been requested after the initial creation.