[wildfly-dev] Copy artifact jar with some files filtered out during wildfly feature build?

Stuart Douglas stuart.w.douglas at gmail.com
Mon Mar 21 04:02:19 EDT 2016


On Mon, 21 Mar 2016 at 18:49 Lin Gao <lgao at redhat.com> wrote:

> Hi,
>
>   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:
> '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.
>
>   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:
>
>   <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. -->
>     <filter pattern="*" include="true"/>
>     <filter pattern="lib/*" include="false" />
>   </copy-artifact>
>
>   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.

Stuart


>
> Best Regards
> --
> Lin Gao
> Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160321/b9472bf7/attachment.html 


More information about the wildfly-dev mailing list