[MASSEMBLY-920] ContainerDescriptorHandler for MetaInf-Services breaks folder structure

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.1.1
• Fix Version/s: 3.3.0
• Assignee: Robert Scholte
• Reporter: Otavio Biasutti
• Created: 30/Jul/19 13:26
• Updated: 26/Apr/20 19:04
• Resolved: 19/Apr/20 09:31

Description

I have my own jar-with-dependecies assembly and I need to use the MetaInf-Services ContainerDescriptorHandler to aggregate all services and avoid overriding.

The plugin does not respect the folder structure inside META-INF/services.

Camel is a good example of dependecy that can be used to reproduce the problem. It defines its services in a nested folder structure, as in:

META-INF/services/org/apache/camel/TypeConverter

What really happens is that the folder structure is indeed created but the TypeConverter file is moved to the root of the services, i.e. META-INF/services

I had to patch the code and define a custom ContainerDescriptorHandler to fix the problem.

The fix is straightforward. I simply inherited the provided implementation of MetaInfServiceHandler and coded an overriden version of the following method like this:

    @Override
    protected String getOutputPathPrefix(final FileInfo fileInfo) {

        return Paths.get(fileInfo.getName()).getParent().toString() + "/";
    }

All services were properly aggreggated after that.

This may be the best fix for several related bugs I found online, like this one here: https://stackoverflow.com/questions/37304195/camel-restlet-not-working-in-jar

Cheer
Otávio

Issue Links

• is duplicated by: MASSEMBLY-812 containerDescriptorHandler metaInf-services breaks services in sub-folders of META-INF/services