maven assembly plugin add certain files of dependency not available in dependencys JAR

Question

To reduce build-time of a multi-module maven project i would like to have own projects for the deployment archives.

We have some standalone batches that are delivered packed as .ZIP using the maven-assembly-plugin. Since currently packing the ZIP is done directly from withing the batch-modules build its no problem to have this two things inside the ZIP:

• /lib with all the dependency- jars (including the Jar with all our batches)
• /script a folder that is not contained in the batch-jar of the module nor in its /target folder. Contains some .BATs/ .CMDs and .properties that are used for development.

When it comes to have a own project to build that ZIP i have no problem to get our dependencys (including our batch-jar containing all the Java based batches and stuff) but i dont know how to include that /script folder which is not part of the modules /target output.

The only way i managed to get it together is by having a relative definition to that folder looking something like this:

<fileSet>
        <directory>${basedir}../my-batches-project/src/main/scripts</directory>
        <includes>
            <include>*</include>
        </includes>
        <outputDirectory>/scripts</outputDirectory>
</fileSet>

This only works if the new project is checked out on the same level as the multip-module project. I wondered if there is a better way of having certain files of a maven project included.

Edit:

Talking back to some team mates we decided to have above mentioned /script folder duplicated in both projects. Inside the deployment-project that builds the ZIP it will remain under src/main/scripts while in the batch-module it will reside in src/test/scripts to allow local execution of the batches ... i however dont like that.

Answer 1

One legit approach would be to maintain the required resources in their own module to populate it to the repository as jar/zip and have a dependency to that new maven module in both of the projects mentioned above.

Considered this is a bit of a overengineered solution in our context we currently argue that packaging of the very-deployment-close ZIPs for our batches happens on a designated build server where there are other "only for production"-files that our "only for developpment"-files are replaced with we can live with the relative path since every of our maven projects is checked out on this build server.