greyblue9 / jarjar

Automatically exported from code.google.com/p/jarjar
0 stars 0 forks source link

JarJar not replacing package names on META-INF/services/ #30

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. download Sun JWSDP 2.0
2.  <jarjar jarfile="${target_jars}/NewJARs.jar">
        <zipfileset src="${jars}/jwsdp/saaj-api.jar"/>
        <zipfileset src="${jars}/jwsdp/saaj-impl.jar"/>
        <zipfileset src="${jars}/jwsdp/xalan.jar"/>
        <zipfileset src="${jars}/jwsdp/xercesImpl.jar"/>
        <rule pattern="com.sun.**" result="com.mycompany.com.sun.@1"/>
        <rule pattern="javax.**" result="com.mycompany.javax.@1"/>
        <rule pattern="org.**" result="com.mycompany.org.@1"/>
    </jarjar>
3. The properties in META-INF/services are not replaced with the
appropriate new package name, e.g. javax.xml.parsers.DocumentBuilderFactory
is still pointing at
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl

What is the expected output? What do you see instead?
Expected to see javax.xml.parsers.DocumentBuilderFactory pointing at
com.mycompany.com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl

What version of the product are you using? On what operating system?
jarjar-1.0

Please provide any additional information below.

Original issue reported on code.google.com by william....@gmail.com on 4 Feb 2009 at 3:47

GoogleCodeExporter commented 8 years ago
It might also be useful to provide an option to strip service definitions.

When library A uses library B repackaged via jarjar it may not be appropriate 
for library A to expose any services from B which could conflict with others 
needed by the user of A.  This would obviously only work when the services from 
B aren't being used by A.

Original comment by matt%hil...@gtempaccount.com on 28 Mar 2011 at 3:00