Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply license header to package-info.java and module-info.java #532

Open
jacek99 opened this issue Feb 28, 2020 · 9 comments
Open

Apply license header to package-info.java and module-info.java #532

jacek99 opened this issue Feb 28, 2020 · 9 comments

Comments

@jacek99
Copy link

jacek99 commented Feb 28, 2020

We added spotless with the Google Java style:

spotless {
    java {
        googleJavaFormat("1.7")
        licenseHeaderFile "${project.rootDir}/company.license.java"
    }
}

and it formatted all code...but left all the package-info.java classes untouched when we run spotlessJavaApply

is that expected behaviour or a bug? How can we force the format to include those files as well?

@jacek99 jacek99 changed the title Gradle java format is not applied to pacakge-info.java files Gradle java format is not applied to package-info.java files Feb 28, 2020
@jacek99 jacek99 changed the title Gradle java format is not applied to package-info.java files Gradle Google java format is not applied to package-info.java files Feb 28, 2020
@nedtwigg nedtwigg changed the title Gradle Google java format is not applied to package-info.java files Apply license header to package-info.java and module-info.java Feb 28, 2020
@nedtwigg
Copy link
Member

I believe google-java-format is applied to these files, it's only the license header step which is not.

if (LicenseHeaderStep.name().equals(step.getName())) {
return step.filterByFile(LicenseHeaderStep.unsupportedJvmFilesFilter());
} else {

private static final SerializableFileFilter UNSUPPORTED_JVM_FILES_FILTER = SerializableFileFilter.skipFilesNamed(
"package-info.java", "package-info.groovy", "module-info.java");

In order to fix this, we would need a smarter delimiter for detecting the start of these files:

// If this constant changes, don't forget to change the similarly-named one in
// testlib/src/test/java/com/diffplug/spotless/generic/LicenseHeaderStepTest.java as well
static final String LICENSE_HEADER_DELIMITER = "package ";

The trick is that we'll need a different delimiter depending on what the filename is. This is possible, but most of our steps are filename-agnostic.

Workaround

You can do something like this (untested):

spotless {
    java {
        googleJavaFormat("1.7")
        licenseHeaderFile "${project.rootDir}/company.license.java"
    }
    format 'javaMisc', {
        target 'src/**/package-info.java', 'src/**/module-info.java'
        licenseHeaderFile "${project.rootDir}/company.license.java", 'some-delimiter-i-dont-know-what'
    }
}

@jbduncan
Copy link
Member

jbduncan commented Feb 28, 2020

I'm actually not sure if google-java-format has any specific support for package-info.java and module-info.java files.

A quick search on GitHub suggests that it doesn't crash when formatting module-info.java files and perhaps package-info.java ones as well, but not necessarily that they're formatted neatly or at all, which your experience seems to confirm.

Thus I'd suggest that you keep an eye here for module-info.java support. As for package-info.java support, I'm not entirely sure...

@nedtwigg I admit I fail to see how your example above would allow (package|module)-info.java files to be formatted with google-java-format. Would you mind clarifying for me?

@nedtwigg
Copy link
Member

I fail to see how your example above would allow (package|module)-info.java files to be formatted with google-java-format.

Most of our users don't realize that the "steps" are independent - it feels like they're configuring one step. -info.java files have very little java content - their most noticeable part is their javadoc / license header.

In @jacek99's original example, google-java-format is already being applied to -info.java files, and it's easy to miss that your single "package blah;" declaration had some whitespace trimmed by google-java-format, when what you expected was a license header.

That's why I focused this issue to say "Spotless does delegate out to your formatter, but it is a known limitation that the license header part will not happen, this is why, and this is how you can fix it or work around it".

@jbduncan
Copy link
Member

jbduncan commented Mar 6, 2020

In @jacek99's original example, google-java-format is already being applied to -info.java files, and it's easy to miss that your single "package blah;" declaration had some whitespace trimmed by google-java-format, when what you expected was a license header.

Ahh, okay, I'd completely misunderstood what was happening here; I thought the problem was that google-java-format wasn't being applied to those files by default!

Thanks for clarifying @nedtwigg. :)

@alvarosanchez
Copy link

Just to confirm that @nedtwigg's workaround works simply by using package as delimiter:

spotless {
    java {
        ...
    }
    format 'javaMisc', {
        target 'src/**/package-info.java', 'src/**/module-info.java'
        licenseHeaderFile rootProject.file('config/spotless.license.java'), 'package '
    }
}

@alvarosanchez
Copy link

Actually I take that back. It does apply the license, but also remove the Javadoc

@alvarosanchez
Copy link

Using '\\/\\*\\*' as delimiter seems to do the trick, but I guess it won't work with packages without Javadoc

@nedtwigg
Copy link
Member

nedtwigg commented Jun 1, 2020

As best we could tell, there wasn’t a single regex that worked for all cases, you need a full Java parser, which is why it has gone unsupported so long.

@deepakdaneva
Copy link

deepakdaneva commented Oct 27, 2023

I am using eclipse.xml formatting rules. Any workaround to apply the header to package-info.java or module-info.java?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants