[MRESOURCES-281] allow different encodings for files inside the same resource-directory

[jira-importer]

Carsten Rohde opened MRESOURCES-281 and commented

Currently each resource-directory has a single encoding, with the recent exception of properties (MRESOURCES-171).

If you need to filter differently encoded files, this can become quite a hazzle: The only way (at least that I'm aware of) is to have different modules or non-resource directories as the source for copy-resources. Apart from bloating the pom, it also forces you to have related files at different locations if they are encoded differently.

 

What I'm suggesting is to generalize what has been done for properties by allowing to override the <encoding> for specific files/patterns.

Ideally this would be part of the resource-declaration but being able to configure the resources plugin accordingly would already help a lot:

<configuration>
   <encodingOverrides>
       <encodingOverride>
          <encoding>UTF-16</encoding>
          <includes>**/*.myfile</includes>
       </encodingOverride>
       <encodingOverride>
           <encoding>iso-latin-1</encoding>
           <includes>**/*.other</includes>
       </encodingOverride>
   </encodingOverrides>
</configuration>

What do you think?

---

Affects: 3.2.0

Issue Links:

• MRESOURCES-88 Allow specific encoding per group of files

[jira-importer]

Michael Osipov commented

I guess this will likely never happen. Why do you need this?

[jira-importer]

Carsten Rohde commented

e.g. I have some files that are related but require a specific encoding (based on their type, like sql, properties, xml etc.). These are mainly older files and older processes in a huge project where these things cannot easily be changed.

I agree that this probably isn't the most mainstream requirement but still, it keeps bothering me a bit and i can imagine other people having a similar problem. I just found the MRESOURCES-88 which seems at least related but hasn't raised much attention either.

[jira-importer]

Michael Osipov commented

Unless they aren't filtered, does it matter?

[jira-importer]

Carsten Rohde commented

Some of them are, that's the thing, but I understand that it's hard to justify the effort if there is not much need for this feature.

[jira-importer]

Carsten Rohde commented

I just scanned my projects for further cases where this issue matters and I think there is another (more common, I think) case for this feature-request:

I've got a project where we use cp1252 as the global resource encoding since many of the resources are windows-targeted. There are however resources that, by convention, require a specific encoding such as xml (as indicated by the encoding declaration), json (where utf-8 is the de facto standard) or yaml (which requires utf-8, utf-16 or utf-32 afaik).

With the latter formats gaining in numbers, there is no real standard encoding for resources in this project anymore. Using copy-resources with custom resource-direcotries is not a very convenient solution as these directories don't show up as resources in your ide and artificially having separate modules sounds even worse to me.

 

What do you think: Does this make this issue any more likely to gain traction?

[jira-importer]

Michael Osipov commented

Yes, I see. But those which have welldefined encoding can be expected on a global basis, unless you need to filter them. As for the post assembly: I have the same idea, but that won't work in any IDE.

[jira-importer]

Carsten Rohde commented

The problem is, in principal we need to filter both. Maybe I'm going with copy-resources instead, but it still feels like the second-best solution imho. Not taking complexity and effort into account, probably the nicest thing would be to add an optional encoding element to the resource element. But this exceeds the limit of the pom schema afaik.

[jira-importer]

Carsten Rohde commented

Just in case anyone else has the same problem. We finally ended up with the following:

• create a folder e.g. src/main/filtered-resources-<encoding>
• use resources:copy-resources with the required encoding encoding to copy into the output directory
• (Eclipse) use build-helper:add-resource or a resource element to add the folder as a project resource folder and then exclude everything inside, thus tricking eclipse into rendering the folder as a first-clas resource-folder
• (Eclipse) ensure that resources:copy-resources is bound by m2e

 

[gnodet]

This is being addressed in apache/maven-filtering#406, which adds per-resource inputEncoding / outputEncoding fields on the Resource class, along with a new outputEncoding field on MavenResourcesExecution. The separate input/output encoding support (MRESOURCES-232) is included in the same PR. A follow-up PR to maven-resources-plugin will expose these as Mojo parameters.