[ 
https://issues.apache.org/jira/browse/MSHADE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Holzner updated MSHADE-221:
------------------------------------
    Description: 
This bug is related to fix https://issues.apache.org/jira/browse/MSHADE-190

Actually in MSHADE-190 it seems that the relocation of entries within 
META-INF/services/* files is implemented.

However, it is also necessary to rename the files itself if they start with the 
affected pattern name.

If it is not done, this is causing issues with e.g. Lucene relocation:

- org.apache.lucene.* package names are relocated successfully throughout our 
project
- within META-INF/services there is a file called org.apache.lucene.codecs.Codec
- the contents of that file are relocated successfully, but the file name 
itself (which is actually the SPI class name) is not changed and will not be 
found after relocating because it is not being correctly relocated as well

When we open the resulting JAR file and rename org.apache.lucene.codecs.Codec 
to [relocationPrefix].org.apache.lucene.codecs.Codec - everything works as 
expected.

See 
https://docs.oracle.com/javase/7/docs/api/java/util/spi/LocaleServiceProvider.html
"A provider identifies itself with a provider-configuration file in the 
resource directory META-INF/services, >>> using the fully qualified provider 
interface class name as the file name <<<"


  was:
This bug is related to fix https://issues.apache.org/jira/browse/MSHADE-190

Actually in MSHADE-190 it seems that the relocation of entries within 
META-INF/services/* files is implemented.

However, it is also necessary to rename the files itself if they start with the 
affected pattern name.

If it is not done, this is causing issues with e.g. Lucene relocation:

- org.apache.lucene.* package names are relocated successfully throughout our 
project
- within META-INF/services there is a file called org.apache.lucene.codecs.Codec
- the contents of that file are relocated successfully, but the file name 
itself (which is actually the SPI class name) is not changed and will not be 
found after relocating because it is not being correctly relocated as well

When we open the resulting JAR file and rename org.apache.lucene.codecs.Codec 
to [relocationPrefix].org.apache.lucene.codecs.Codec - everything works as 
expected.


> ServicesResourceTransformator is not renaming the files itself in 
> META-INF/services
> -----------------------------------------------------------------------------------
>
>                 Key: MSHADE-221
>                 URL: https://issues.apache.org/jira/browse/MSHADE-221
>             Project: Maven Shade Plugin
>          Issue Type: Bug
>    Affects Versions: 2.4.3
>            Reporter: Reinhard Holzner
>
> This bug is related to fix https://issues.apache.org/jira/browse/MSHADE-190
> Actually in MSHADE-190 it seems that the relocation of entries within 
> META-INF/services/* files is implemented.
> However, it is also necessary to rename the files itself if they start with 
> the affected pattern name.
> If it is not done, this is causing issues with e.g. Lucene relocation:
> - org.apache.lucene.* package names are relocated successfully throughout our 
> project
> - within META-INF/services there is a file called 
> org.apache.lucene.codecs.Codec
> - the contents of that file are relocated successfully, but the file name 
> itself (which is actually the SPI class name) is not changed and will not be 
> found after relocating because it is not being correctly relocated as well
> When we open the resulting JAR file and rename org.apache.lucene.codecs.Codec 
> to [relocationPrefix].org.apache.lucene.codecs.Codec - everything works as 
> expected.
> See 
> https://docs.oracle.com/javase/7/docs/api/java/util/spi/LocaleServiceProvider.html
> "A provider identifies itself with a provider-configuration file in the 
> resource directory META-INF/services, >>> using the fully qualified provider 
> interface class name as the file name <<<"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to