Search code examples
javaspringdependency-injectionconventioncomponent-scan

Is there a naming convention for @ComponentScan basePackageClasses?


Spring's @ComponentScan offers a type-safe basePackageClasses attribute - seems a good thing to use especially as it isn't uncommon for packages to be renamed on the project I'm working on. The documentation says:

Consider creating a special no-op marker class or interface in each package that serves no purpose other than being referenced by this attribute.

... but offers no further guidance on the name of such a class. Am wondering if there are any conventions around this. package-info.java already exists in all packages (as enforced by Checkstyle) - would have preferred to reuse this but sadly Java doesn't allow a class of this name.

(If no such standards exist am thinking perhaps PackageInfo, BasePackage, PackageMarker or similar but would prefer to follow convention if there is one.)


Solution

  • No answers yet and had to make a decision so here it is:

    Marker class:

    package com.companyname.appname.projectname.package1name;
    
    /**
     * Empty marker class used to identify this package when using type-safe basePackageClasses in Spring @ComponentScan.
     */
    public class PackageMarker {
        // Empty marker class
    }
    

    Usage:

    @ComponentScan(basePackageClasses = {
        com.companyname.appname.projectname.package1name.PackageMarker.class,
        com.companyname.appname.projectname.package2name.PackageMarker.class,
        /* ...etc... */
    })
    

    PackageMarker naming justification:

    1. Seems sensible for all such classes to have the same name so they can be easily identified.
    2. Seems sensible for it to start with "Package" (in the same way as package-info.java).
    3. Seems sensible for it to end with "Marker" since the documentation refers to a "marker class".
    4. Opted not to include the word "Base" so it isn't confused with base classes.
    5. Opted not to include the word "Info" as it doesn't contain any info like package-info.java does.
    6. Opted not to include any other words (e.g. "NoOp") to keep it snappy and flexible for other possible uses.

    Would still be interested if anyone can give examples of marker classes used in a more trail-blazing context...