3 Replies Latest reply on Feb 7, 2005 5:07 PM by Adrian Brock

    Adding Resources To Artifacts


      I'm working on the jmx module which requires some resources to be added to the jar. However, I'm at a loss on how to proceed. I think I need to do something like this:

       <source id="main">
       <source id="resources"/>
       <artifactdef artifact="jboss-jmx.jar">
       <include input="main">
       <include pattern="**"/>
       <exclude pattern="test/**"/>
       <include input="resources">
       <include pattern="dtd/*.dtd"/>
       <!-- include descriptor for MBean Info DB service -->
       <include pattern="*-xmbeandd.xml"/>

      However, this results in resources being compiled like source code because of the [source] node in the build targetdef. What would seem ideal is to add a [resource] subelement to componentdef which would allow me to handle it seperately in the build targetdef. Or perhaps there is an existing mechanism that I am overlooking for adding resources to a jar (likely).

      I know one of the TODO's is to add build.resources targetdef, but I'm unclear where to hook it so that it only applies to components that need it.
      A [resource] element in the build targetdef seems the natural place.

        • 1. Re: Adding Resources To Artifacts
          Adrian Brock Master

          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

          <resources id="jbossmq-httpil"/>

          With a directory structure

          Which would mean src/resources/jbossmq-httpil is only used internally
          and could be referenced from a jar build

          <include input="jbossmq-httpil"/>

          versus a real artifact of the build

          <artifact id="jbossmq-service.xml"/>

          which would be located (by default) in
          output/resources - for the src build
          thirdparty/(project.id)/resources - for the binary build

          • 2. Re: Adding Resources To Artifacts

            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 input="resources-root">
             <include pattern="dtd/*.dtd"/>
             <include pattern="MBeanInfoDB-xmbeandd.xml"/>

            • 3. Re: Adding Resources To Artifacts
              Adrian Brock Master

              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.