Maven: How to manage platform-specific files like startscripts (not libraries)

Question

Hello everyone!

I have a java project consisting of three modules

• project-common
• project-a
• project-b

Project a and b use -common as dependency.

I use a simple assembly configuration to put project-a, project-b and all dependent libraries (spring and so on) in a single archive.

I also want to provide startscripts for different platforms (windows32, windows64, linux32, linux64 and macosx). For example I will use for windows winrun4j and sh-scripts for linux.

What is the best approach to manage these files (as they don't need any compilation etc. like native libraries)?

Currently I placed the startfiles for every project in its /main/resources/bin folder resulting in an assembly were all startscripts for alle platforms end up.

Is there some clevery why to move these startfiles into dedicated modules and manage them somewhow to be able to build "platform specific" assemblies including only the startfiles for a given platform?

Answer 1

You can use profiles activation and OS detection :

<profiles>
    <profile>
        <activation>
            <os>
                <family>windows</family>
                <arch>x86</arch>
            </os>
        </activation>
        ....
    </profile>
</profiles>

---

Resources :

• Introduction to build profiles
• Maven enforcer plugin - Require OS Version

On the same topic :

• Maven: Finding out whether running in a 32 or a 64 bit JVM

Answer 2

Is there some clevery why to move these startfiles into dedicated modules and manage them somewhow to be able to build "platform specific" assemblies including only the startfiles for a given platform?

If only the startup scripts are platform specific (and not the code) then I wouldn't bother building platform specific assemblies and just bundle all of them together.

Building platform specific assemblies will make your build more complicated, harder to maintain, longer to run, and all this without providing much added value to users. It doesn't seem worth it.

And that's indeed just not what most projects are doing, for example:

Tomcat (simple case)

With Tomcat, you get both .sh and .bat versions of the scripts in the bin directory

pascal@laptop:~$ cd ~/opt/apache-tomcat-6.0.29/bin
pascal@laptop:~/opt/apache-tomcat-6.0.29/bin$  ls
bootstrap.jar       digest.bat        shutdown.sh           tool-wrapper.sh
catalina.bat        digest.sh         startup.bat           version.bat
catalina.sh         jsvc.tar.gz       startup.sh            version.sh
catalina-tasks.xml  setclasspath.bat  tomcat-juli.jar
commons-daemon.jar  setclasspath.sh   tomcat-native.tar.gz
cpappend.bat        shutdown.bat      tool-wrapper.bat

Sonar (complex case)

Sonar might be a better example, similar to your situation. With Sonar, the bin directory contains platform specific subdirectories with scripts for each platform:

pascal@laptop:~$ cd ~/opt/sonar-2.2/bin/
pascal@laptop:~/opt/sonar-2.2/bin$ ls
aix-ppc-32      hpux-parisc-64  linux-x86-64         solaris-x86-32
aix-ppc-64      linux-ia-64     macosx-universal-32  solaris-x86-64
hpux-ia-32      linux-ppc-32    macosx-universal-64  windows-x86-32
hpux-ia-64      linux-ppc-64    solaris-sparc-32
hpux-parisc-32  linux-x86-32    solaris-sparc-64
$ cd linux-x86-32/
$ ls
lib  sonar.sh  wrapper

Personally, I don't care having platform specific versions of startup files in a single archive, au contraire: I don't have to find and download the "right" archive, I can unpack it on several platform, etc.

Of course, all the above applies only if the binaries themselves are not platform specific. If they really are, using platform specific assembly descriptors, probably profiles for the dependencies and running your build for each platform would be the way to go.