Umbrella-Issue for further ideas

[nilshartmann]

This Issue should collect basic ideas for further Deptective features. Feel free to comment! In case an idea should be implemented we can spawn a new issue for that idea to finer discuss and/or implement it.

Allow "Package-Pattern"?

Using pattern in Package in "packages" and/or "names" one could easier setup Deptective (esp for existing projects) and one could group packages in "logical layers".

For Example: all UI-Packages are allowed to use all util-Packages:

{
    "packages" : [
        {
            "name" : "org.microshop.ui.*",
            "reads": [ "org.microshop.util.*" ]
        }
    ]
}

An alternative could be to introduce the concept of a layer. A layer could be a group of packages (and allowed dependencies). Another package then could reference either single packages or complete layers.

Another term for "reads"

Not sure, but for me "reads" sounds like this package actually is reading the listed packages. Maybe "allowed" or something would be better?

Dealing with parent/child packages

Should there be a default handling regarding access from parent packages to child packages and/or vice versa? For example: is "com.bla" allowed to access "com.bla.internal" or the other way round without specifying it explicitly?

Handling of packages that have no description

• Currently the plug-in fails if it finds compilation unit inside of a package without any description. Maybe we should change this to warning/info (or configurable via option) to make adopting the plugin easier? Currently one has to define all reads for the whole app.

Differentiate between "allowed" and "unwanted" dependencies

Could be useful to "deprecated" package usage (esp for existing apps that are going to be refactored). "Deprecated" dependencies would result in a warning but never in an error during compilation.

[gunnarmorling]

Thanks, that's great input!

Allow "Package-Pattern"

I was talking to @wuetherich, and he also suggested the notion of layers, so that's definitely something to consider.

Another term for "reads"

On the "reads" term, it's what's used by the Java Module System (one module "reads" another one), hence I went for that.

Dealing with parent/child packages

I think I'd prefer explicitly defined reads relationships at least for the time being, but It's something that could be done down the road.