On Mon, 21 Mar 2016 at 18:49 Lin Gao <lgao(a)redhat.com> wrote:
There is an issue on composing native bits of Artemis during wildfly
full-feature-pack build, that the 'libartemis-native.so' is duplicated.
One is at:
and another is at: 'lib/linux-i686/libartemis-native-.so' in the
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.
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.
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:
extract="FALSE"> <!-- Sets extract to false with some filters defined.
<filter pattern="*" include="true"/>
<filter pattern="lib/*" include="false" />
Do you guys think it makes sense?
No the following reasons:
- 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.
- This cannot be done for servers that use maven artifact references, so
you will get a better result depending on how it is provisioned.
- In general I don't think editing 3rd party jar files as part of our build
process is a good idea.
JBoss by Red Hat
wildfly-dev mailing list