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

Allow custom file extensions to help identify which formatter to use #427

Closed
richardwalsh opened this issue Jan 21, 2021 · 4 comments
Closed

Comments

@richardwalsh
Copy link

It would be great if I could provide the plugin a configuration to override the default extensions that are used to identify which formatter to use. I suppose it could go overboard with a comma separate list or regex, but for my needs it could be something as simple the following snippet:

<configuration>
      <jsonFileExtension>avsc</jsonFileExtension>
      <htmlFileExtension>HTM</htmlFileExtension>
</configuration>

The motivation for this is I want to use the plugin to reformat Avro schema definitions that are in written in json but are defined in files with the extension of ".avsc". That is a problem because the FormatterMojo.doFormatFile() only performs json formatting for files with the normal extension of ".json".

Thanks

@ctubbsii
Copy link
Member

ctubbsii commented Jan 21, 2021

The normal <includes/> and <excludes/> patterns like described in the documentation would work well if the formatters were separated into different mojos, as described in #254 . Then, this feature wouldn't be needed.

@richardwalsh
Copy link
Author

The normal <includes/> and <excludes/> patterns like described in the documentation would work well if the formatters were separated into different mojos, as described in #254 . Then, this feature wouldn't be needed.

Totally agree. In my case, use something like format-json and use the directory and includes/excludes to identify the candidates.

@ctubbsii
Copy link
Member

@richardwalsh Since #254 is the preferred solution, are you okay with closing this issue for now, so that any contributors interested in creating a PR for to support this use case will focus instead on that other issue rather than this one?

@richardwalsh
Copy link
Author

Sure that works

This issue was closed.
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

2 participants