How to substitute a variable with real value in a xml file , which is in another dependency jar file by Maven

We have a project called web-app1 and has a dependency on another jar file called core-app.jar which is provided by another team as a shared library , yet there is a hibernate.cfg.xml in this core-app.jar (inside of the jar), with content as below.

<hibernate-configuratio开发者_开发问答n>
    <session-factory>
        <property name="dialect">${hibernate.dialect}</property>
        <property name="query.substitutions"><![CDATA[false 'N', true 'Y']]></property>
        <property name="show_sql">false</property>
        <property name="format_sql">false</property>
        <property name="use_sql_comments">false</property>
        <property name="generate_statistics">true</property>
        <property name="hibernate.connection.release_mode">after_transaction</property>
       <!-- Search Configurations -->
        <property name="hibernate.search.default.directory_provider">org.hibernate.search.store.FSDirectoryProvider</property>
        <property name="hibernate.search.default.indexBase">${lucene.index.home}</property>
        <property name="hibernate.search.default.batch.merge_factor">10</property>
        <property name="hibernate.search.default.batch.max_buffered_docs">10</property>
    </session-factory>
</hibernate-configuration>

As we see in the Search Configurations section, there is a variable ${lucene.index.home} that should be replaced by other projects on different OS platform,

so the question, does maven provide a way to filter a dependency jar file and filter the content? any plugins ? war:war , unzip ? dependencies ? I couldn't figure a fast way to do that. it looks to me , no matter what plugin would be adopted, the plugin needs to do 4 things basically.

• 1 unpack the jar in process-resources phase.
• 2 substitute the ${var} with value defined in profile.
• 3 pack it again back into a jar.
• 4 need to copy it back from the packing/unpacking workspace back to the maven process path ??

did anyone run into this similar requirement before.

thanks

---

I would assume that those values are meant to be set at runtime, likely as VM arguments. It doesn't make sense to provide a jar file that has to be modified to be able to be used.

---

If you really really REALLY have to do filtering at build time for configuration purposes, those configuration files should be filtered, NOT your dependencies. Then, you should either bundle said file into multiple artifacts (assuming of course you are targeting multiple environments), or be provided outside the built artifact as an externalized resource.