This is something I didn't test.
I'm not sure how best to define it.
src/resources can contain both artifacts and internal build components.
e.g. It might contain META-INF/jboss-service.xml for inclusion in a sar
(i.e. it is not a direct artifact of the build)
or it might contain jbossxxxx-service.xml for inclusion in the released project,
in this case it is a direct artifact of the build
The basics of build.resources is to copy src/resources to output/resources
(with potentially some replacement).
But personally I think it would be a good idea to identify how the resources
relate to the build.
Like you said we could have a
With a directory structure
Which would mean src/resources/jbossmq-httpil is only used internally
and could be referenced from a jar build
versus a real artifact of the build
which would be located (by default) in
output/resources - for the src build
thirdparty/(project.id)/resources - for the binary build
I have implemented this with a small change. The problem I ran into in the jmx module is that resources were rooted in src/resources instead of some subdirectory.
<include pattern="dtd/*.dtd"/> <include pattern="MBeanInfoDB-xmbeandd.xml"/>
To accomodate this, I needed a resource path of id ".", which didn't look right from a usability perspective, so I added a path attribute:
<resource id="resources-root" path="."/>
The id can be used by default to specify both the name and the path like a source element. However, this gives the flexibility to have an id different from the path.
<artifactdef artifact="jboss-jmx.jar"> <include input="main"> <include pattern="**"/> <exclude pattern="test/**"/> </include> <include input="resources-root"> <include pattern="dtd/*.dtd"/> <include pattern="MBeanInfoDB-xmbeandd.xml"/> </include> </artifactdef>
Ok. It is only used internally anyway so we don't need to worry about whether
it is relative to a source or binary build.
In general, it would probably be an idea to fix these such that we know what the
resources relate to, i.e. those files would be better moved to
It also makes it easier for somebody to come along later and add resources
that do not relate to that jar.