<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 21 Mar 2016 at 18:49 Lin Gao <<a href="mailto:lgao@redhat.com">lgao@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
There is an issue on composing native bits of Artemis during wildfly full-feature-pack build, that the 'libartemis-native.so' is duplicated.<br>
One is at: 'modules/system/layers/base/org/apache/activemq/artemis/main/lib/linux-/libartemis-native-.so', and another is at: 'lib/linux-i686/libartemis-native-.so' in the artemis-native.jar file.<br>
<br>
The duplication of the native bits will confuse the user which one is actually used, and which one to patch in case of one-off.<br></blockquote><div><br></div><div>Will it thought? The only way they will know the other one is there is if they unzip the jar file, which seems unlikely. In terms of patches the patch tool should just update the bits that need to be replaced, I don't see how there would be the potential for confusion.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
IMHO, we can add support in wildfly-build-tool to copy a jar file with some files excluded, so that we can filter out the 'libartemis-native-.so' in the artemis-native.jar during the wildfly-full-featch-pack build, like:<br>
<br>
<copy-artifact artifact="org.apache.activemq:artemis-native" to-location="modules/system/layers/base/org/apache/activemq/artemis/main/" extract="FALSE"> <!-- Sets extract to false with some filters defined. --><br>
<filter pattern="*" include="true"/><br>
<filter pattern="lib/*" include="false" /><br>
</copy-artifact><br>
<br>
Do you guys think it makes sense?<br></blockquote><div><br></div><div>No the following reasons:<br><br></div><div>- The feature pack is the definition of the server, not the resulting build from a server. We are telling downstream projects (such as swarm) to build from these feature packs, so this change would not be propagated to downstream projects. Also if a user provisioned directly from feature packs this change would not be present.<br><br></div><div>- This cannot be done for servers that use maven artifact references, so you will get a better result depending on how it is provisioned.<br><br></div><div>- In general I don't think editing 3rd party jar files as part of our build process is a good idea.<br><br></div><div>Stuart<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best Regards<br>
--<br>
Lin Gao<br>
Software Engineer<br>
JBoss by Red Hat<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div></div>