Upgrade to JSW 3.5.x to provide access for newer JSW configuration features (like auto restart after JVM hang).

If there are restrictions on JSW binary distribution then please add an option for plugin to use locally provided JSW binaries.

while using this environmentSetupFileName in pom.xml ,values given in the environmentSetupFileName xml tag is not treating the value as same.while creating .bat file it is using the value with suffix .bat and while creating .sh file it is not using the value with suffix .sh.

eg. aaa

In the batch file that is created after building the project ,the value is
"if exist "%BASEDIR%\bin\aaa.bat" call "%BASEDIR%\bin\aaa.bat""

In the script file that is created after building the project,the value is
[ -f "$BASEDIR"/bin/aaa ] && . "$BASEDIR"/bin/aaa

why it is not suffixing with .sh in the above command.

If you run the integration tests you see that the binFolder and binFileExtensions change the folder and extensions as expected.

However, if you use the generate-daemons mojo neither have any effect.

I want to change the bin folder to the root (should that be . or an empty tag? the docs aren't clear) and I want to suffix my daemon shell scripts with .sh.

The plugin requires you to change your maven project name if you want to change the app long name in the script.

It is fine to default to context.setProperty( "app.long.name", request.getMavenProject().getName() ); but there should be an option within the plugin settings to change it.

As per http://stackoverflow.com/q/32277074/1000011

I am only targeting Solaris when using Appassembler and have this in my pom

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.stackoverflow</groupId>
  <artifactId>question</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging> 

  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>appassembler-maven-plugin</artifactId>
        <version>1.10</version>
        <executions>
          <execution>
            <id>generate-jsw-scripts</id>
            <phase>package</phase>
            <goals>
              <goal>generate-daemons</goal>
            </goals>
          </execution>
        </executions>

        <configuration>
          <repositoryLayout>flat</repositoryLayout>
          <includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath>
          <target>${project.build.directory}</target>
          <configurationDirectory>conf</configurationDirectory>
          <daemons>
            <daemon>
              <id>${project.artifactId}</id>
              <mainClass>org.apache.catalina.startup.Bootstrap</mainClass>
              <jvmSettings>
                <initialMemorySize>512</initialMemorySize>
                <maxMemorySize>1024</maxMemorySize>
                <extraArguments>
                  <extraArgument>-Dapp=${project.artifactId}</extraArgument>
                  <extraArgument>-XX:MaxPermSize=128m</extraArgument>
                  <extraArgument>-XX:+UseParNewGC</extraArgument>
                  <extraArgument>-XX:+CMSParallelRemarkEnabled</extraArgument>
                  <extraArgument>-XX:+UseConcMarkSweepGC</extraArgument>
                </extraArguments>
              </jvmSettings>

              <platforms>
                <platform>jsw</platform>
              </platforms>
              <generatorConfigurations>
                <generatorConfiguration>
                  <generator>jsw</generator>
                  <includes>
                    <include>solaris-x86-32</include>
                  </includes>
                  <configuration>
                    <!--Logging-->
                    <property>
                      <name>wrapper.logfile.maxsize</name>
                      <value>10m</value>
                    </property>
                    <property>
                      <name>wrapper.logfile.maxfiles</name>
                      <value>10</value>
                    </property>
                  </configuration>
                </generatorConfiguration>
              </generatorConfigurations>
            </daemon>
          </daemons>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

However, a bat file is still generated and there is a Windows specific section in the generated conf.

Neither are going to stop me running - for instance I can exclude the bat file when using the assembly plugin and I don't think the Windows section will affect me on Solaris.

However, for neatness sake I would rather not generate either in the first place.

The new home of this project here on github was kinda hard to find. Several pieces of information are misleadingly wrong now that codehaus.org is gone (right?).
The issues link on http://www.mojohaus.org/appassembler/appassembler-maven-plugin/issue-tracking.html points at non-existent http://jira.codehaus.org/browse/MAPPASM should point to https://github.com/mojohaus/appassembler/issues , code links to http://www.mojohaus.org/appassembler/appassembler-maven-plugin/source-repository.html should point https://github.com/mojohaus/appassembler, etc.

I had to revert mojo-parent to 39 in preparation for releasing appassember-m-p-2.0

Here is the error when user with mojo-parent-40
org.codehaus.mojo.appassembler.daemon.jsw.JavaServiceWrapperDaemonGeneratorTest.testGenerationWithChkConfig(JavaServiceWrapperDaemonGeneratorTest.java:307)
Caused by: com.google.inject.ProvisionException:
Guice provision errors:

1. Error injecting: org.apache.maven.artifact.transform.DefaultArtifactTransformationManager
   at ClassRealm[plexus.core, parent: null]
   at ClassRealm[plexus.core, parent: null]
   while locating org.apache.maven.artifact.transform.ArtifactTransformationManager
   while locating org.apache.maven.artifact.resolver.DefaultArtifactResolver

Since configurationDirectory is configurable in the goal, it would be useful to pass this value through the app launcher scripts just like app.home, etc get passed.

e.g. a property like this on the jvm line of the generated script:

-Dapp.config=etc

And then at run time the user can grab the app.home + app.config to resolve the path to their configuration files.

Upgrade to mojo-parent version 36.

We use appassembler to generate a Java Daemon based on JSW. This daemon runs as a service in an Unix environment.
We use traditional Sysvinit to configure this service.
But when server reboots, the following error occurs:
FATAL | wrapper | Unable to resolve the full path of the configuration file, /etc/conf/wrapper.conf: No such file or directory

I think this problem is caused by the fact we use multiple levels of soft link.

Our shell script (generated by the plugin) is named "myDaemon".
Content of folder /etc/init.d:
myDaemon -> ../../home/myApss/bin/myDaemon
Content of folder /etc/rc2.d: (we start at runlevel 2):
S20myDaemon -> ../init.d/myDaemon

The unix template of the plugin doesn't deal with multiple levels of soft link. See appassembler-maven-plugin/src/main/patches/sh.script.in
As a workaround we use a modified version of this unix template. If you think my analyse is ok, I can create a pull request with our fixed unix template.

Hi, we are having problems with generated app assembler when project's base folder contains %2F.
We work with jenkins and bitbucket, when we create a new branch called feature/application-assembly, Jenkins create a folder feature%2Fapplication-assembly to compile it.

In this case, the plugin is generating the scripts in folder:
feature%2Fapplication-assembly/.....

But JAR files are installing in:
feature/application-assembly/....

So, the script doesn't work.

Could you help us?

Thank you

If i define the following:

<daemons>
    <daemon>
      <id>mod-dev</id>
    </daemon>
    <daemon>
      <id>mod-test</id>
    </daemon>
    <daemon>
      <id>mod-prod</id>
    </daemon>
</daemons>

This would generate the following folder structure:

+---jsw
    +---mod-dev
    ¦   +---bin
    ¦   +---etc
    ¦   +---lib
    +---mod-test
        +---bin
        +---etc
        +---lib

And it will unfortunately generate also the batch/shell scripts like this:

mod-dev/bin/mod-dev.bat
mod-dev/bin/mod-dev

mod-test/bin/mod-test.bat
mod-test/bin/mod-test

It would be nice having an configuration option to keep the name of the shell/batch file always the same cause we have a separation based on the folder structure which would result in the following:

mod-dev/bin/mod.bat
mod-dev/bin/mod

mod-test/bin/mod.bat
mod-test/bin/mod

This would make packaging into distribution archives easier.

When creating bat and sh files with assemble there should be possibility to force script to set up working directory before java execution. The problem here is that when executing bat file from different directory then app/bin application base path is set to that other directory rather than app directory. An example:
When we create new File(".") in our application and print its absolute path
D:\test_app> bin\test_app.bin -> D:\test_app\.
but when we try to run the same bat file but from different current directory:
D:\other_dir\my_stuff> D:\test_app\bintest_app.bin -> D:\other_dir\my_stuff\.

This can be done with: pushd %BASEDIR% before calling java and then popd and the end of the script to revert this change. This will ensure that app always has set correct working directory and for example logging libraries that are using relative paths will log to correct directory inside our app folder and not inside current user directory.

Unix script does starts at its BASEDIR. A consistent behavor should be at both place

I want to use the option useAllProjectDependencies=true to also include dependencies in test scope. If I enable this option the transitive dependencies are not copied to the repo directory.

Example

commons-configuration.commons-configuration:1.10 has two transitive dependencies:

• commons-lang.commons-lang:2.6
• commons-logging.commons-logging:1.1.1

These are only copied if I disable useAllProjectDependencies. Is this behavior as designed or a bug?

I'm using appassembler-maven-plugin 1.10 and JDK 1.8.0_71 (32bit).

I have a project that depends on JACOB, a library that depends on a DLL to invoke Windows' ActiveX components. I declare the JACOB's DLL dependency in my project's pom.xml like that:

        <dependency>
            <groupId>net.sf.jacob-project</groupId>
            <artifactId>jacob</artifactId>
            <classifier>x64</classifier>
            <type>dll</type>
            <scope>runtime</scope>
        </dependency>

Note that I declare JACOB's version in a parent POM.

After running appassembler:assemble goal, the DLL isn't copied to my target repository. It does not matter if I change the scope to something else. All other dependencies are, though. This seems to be a problem to a few other users.

This is a request to update appassembler to allow copying of DLLs to the target repository. Alternatively, an user should specify where DLLs are to be placed and appassembler could automaticaly add to the script the needed -Djava.library.path parameter.

Hello,

Currently I am attempting to relocation some of the directories that the wrapper is using. I would like an easily option to be accessible via maven build parameters to be able to which where the pid dir and execution directory are set.

Reasons for the pid dir; We would like to be able to move this to a common 'var' folder, such that we can have an existing version of our app running, then install a new version of it. As they have the same app names and the same pid dir this would result in the same file being used for both versions. This would prevent the new version from starting until the old version has been stopped.

Reasons for moving the execution folder; Some vender products are a little messy, and documentation can be hard to find on how to alter default settings. I often see applications wanting to write things to the folder that the application started in. As this in the bin folder, I often see log files and hotspot files written to this folder. I believe it would be nice to have the option to have the java processes from a different folder to avoid this pollution of the bin/scripts folder.

I look forward to your thoughts
thanks

I think it would be useful if appassembler could help generate the script(s) and app packaging required to make a Java application a Linux daemon or Windows service using the Apache Commons Daemon project.

https://commons.apache.org/proper/commons-daemon/

There are some examples here:

https://github.com/apache/commons-daemon/tree/trunk/src/samples

A side effect of using the showConsoleWindow option set to false is that it causes JavaFx application windows to start minimized. To me this is unexpected.

The problem seems to be the /min part of the line JAVACMD=start /min javaw. When /min is removed it behaves as expected for both JavaFx and Swing (tested in Java 8u161).

Workaround

In my environmentSetupFileName script, I put set JAVACMD=start javaw.

without this, the directory keeps accumulating the old files when user never call 'clean'

Hi!

When running the generate-daemons goal with platform specified as jsw the following JSW wrapper executables is added to the bin/ folder of the generated file structure:

• AIX-ppc-32 bit
• AIX-ppc-64 bit
• Linux-x86 32 bit
• OSX 32 bit
• Solaris-x86 32 bit
• Windows-x86 32bit

It would be great to be able to include 64 bit binaries for common platforms such as Windows and Linux. They are made available from JSW central http://wrapper.tanukisoftware.com/doc/english/download.jsp

I haven't found any way of specifying exactly what platforms to target when using the JSW feature. A configurable option would be a great addition to the plugin.

This is needed cause we changed from JDK 5 to JDK 6 runtime.

The cause is the missing emptyDirectory in the defined integration test which couldn't be checked in with Git.

MAPPASM-201-no-filtering
MAPPASM-201-filtering

This must be created during the setup of the integration tests.

I'm packaging my app using the Maven shade plugin to create an uber jar. I'd like to generate a repo containing the single fat jar and scripts that run the app with a classpath consisting of my config files and the fat jar. I can't seem to find a way to achieve this, is this scenario covered? If not I think it would be a nice to have.
Thanks

Hi,

I am a maintainer of MyBatis Migrations and I recently added endorsedDir to the plugin configuration to support a new feature.
The generated launcher script works fine on my macOS, of course, but a user reported that it does not work on MinGW environment.

The following part of the script appends endorsed dir and it makes classpath string unrecognizable, I guess.

ENDORSED_DIR=
if [ -n "$ENDORSED_DIR" ] ; then
  CLASSPATH=$BASEDIR/$ENDORSED_DIR/*:$CLASSPATH
fi

The full script is in the 3.3.0-SNAPSHOT .zip package.
Please see the pom.xml for the plugin configuration.

Thanks in advance,
Iwao

The assembleDirectory directory could be used as binFolder. But the script doesn't start if it is not in a directory below assembleDirectory.

Shell script generated with useWildcardClassPath=true is not working properly on Git Bash command-line. (MINGW64).

Symptoms:

• When trying to run project on a cygwin console i get: Error: Could not find or load main class
• The Windows bat works fine and the shell script executes fine on Linux machine.
• The shell script works fine on Git Bash when using: useWildcardClassPath=false

After some investigation I've found that the issue is related to the wildcard in path and the fact that cygpath conversion is actually not invoked and for some reasons Unix-style CLASSPATH is ok without wildcard, but with wildcard it is not.

Change from:

# OS specific support.  $var _must_ be set to either true or false.
cygwin=false;
darwin=false;
case "`uname`" in
  CYGWIN*) cygwin=true ;;
  Darwin*) darwin=true

To:

# OS specific support.  $var _must_ be set to either true or false.
cygwin=false;
darwin=false;
case "`uname`" in
  CYGWIN*) cygwin=true ;;
  MINGW*) cygwin=true ;;
  Darwin*) darwin=true

Solves the issue.

Can you incorporate support for git-bash (MINGW64)?
It seems more and more popular nowadays.

Currently both classpath and java.library.path are determined by single setting <repositoryName>lib</repositoryName>.

It would be nice to have them separate like this:

<libDir>lib</libDir>
<nativeDir>bin</nativeDir>

This would prevent classpath scanning problems like this:
ronmamo/reflections#80

15:41:53.023 [WrapperSimpleAppMain] WARN  org.reflections.Reflections - could not create Vfs.Dir from url. ignoring the exception and continuing
org.reflections.ReflectionsException: could not create Vfs.Dir from url, no matching UrlType was found [file:/opt/ecp/lib/wrapper-windows-x86-64.dll]
either use fromURL(final URL url, final List<UrlType> urlTypes) or use the static setDefaultURLTypes(final List<UrlType> urlTypes) or addDefaultURLTypes(UrlType urlType) with your specialized UrlType.
        at org.reflections.vfs.Vfs.fromURL(Vfs.java:108)
        at org.reflections.vfs.Vfs.fromURL(Vfs.java:90) 
        at org.reflections.Reflections.scan(Reflections.java:236)
        at org.reflections.Reflections.scan(Reflections.java:203)
        at org.reflections.Reflections.<init>(Reflections.java:128)

This feature is also requested at https://stackoverflow.com/questions/34334599/appassembler-maven-plugin-how-to-include-native-library-files-when-generating.

Hey,

I'm using 1.10 version of your maven plugin and I'm trying just to generate daemon scripts for unix platform. No matter what I put in configuration I keep getting NullPointerException in DefaultScriptGenerator in method createBinScript. It seems that String binFolder method parameter is always null :( :( :(

According to the website here, specifying a extraJvmArguments will generate scripts where a an env variable EXTRA_JVM_ARGUMENTS is used to pass the specified args. As far as I understand this is no longer the case since MAPPASM-181.

While installing a software's dependencies, appassembler will allways overwriting existing jar files. In many circumstances this may be unnecessary. appassembler should have an option to avoid that.

bash-4.3$ uname -p
powerpc
bash-4.3$ uname -p | tr "[A-Z]" "[a-z]"

This is due to the locale being:
LANG=no_NO

If I add the -A option
uname -p | tr -A "[A-Z]" "[a-z]" | tr -d ' '
powerpc

with lang=US it would work ootb

from man:
-A
Performs all operations on a byte-by-byte basis using the ASCII collation order for ranges and character classes, instead of the collation order for the current locale.

however that option is only available on aix, not linux for instance.

With default config:

<plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>appassembler-maven-plugin</artifactId>
                    <version>1.10</version>
                    <configuration>
<includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath>
                        <platforms>unix</platforms>
                        <target>${project.build.directory}</target>
                        <daemons>
                                <id>${project.name}</id>
                                <mainClass>${appassembler.mainClass}</mainClass>
                                <commandLineArguments>
                                    <commandLineArgument>start</commandLineArgument>
                                </commandLineArguments>
                                <platforms>
                                    <platform>booter-unix</platform>
                                </platforms>
                            </daemon>
                        </daemons>
                    </configuration>
                    <executions>
                        <execution>
                            <id>generate-jsw-scripts</id>
                            <phase>package</phase>
                            <goals>
                                <goal>generate-daemons</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>

plugin fails to generate proper wrapper script and any attempt to run it fails with:

$ sh ./target/booter-unix/bin/job-runner status
Error: Could not find or load main class org.codehaus.mojo.appassembler.booter.AppassemblerBooter

All classpath paths point to repo dir while in reality all files are in lib directory.

Currently

                        <program>
                            <mainClass>com.foo.Server</mainClass>
                            <id>foo-server</id>
                            <jvmSettings>
                                <maxMemorySize>8g</maxMemorySize>
                            </jvmSettings>
                        </program>

generates scripts including

exec "$JAVACMD" $JAVA_OPTS -Xmx8g \
  -classpath "$CLASSPATH" \

It would be useful if the environment variable $JAVA_OPTS could override Xmx by providing a duplicate JVM flag with a different value (-Xmx16g). It is weird to have duplicate values for a given JVM flag, and resulting behavior surely varies across JVMs, but nonetheless, this would be useful as an option to customize a deployment for a server using only environment variables.

With this new flag (javaOptsAfterJvmSettings?), the generated script would include

exec "$JAVACMD" -Xmx8g $JAVA_OPTS \
  -classpath "$CLASSPATH" \

I trid the "generate-daemons" goal with both version 1.10 and latest 2.0.0 on Antergos Linux.

Trying to run the generated daemon on a Ubuntu 16.04.3 LTS fails.
The error seems to be that somewhere down the line a call to wrapper-linux-x86-64 -v fails with

.../wrapper-linux-x86-64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.3' not found (required by .../wrapper-linux-x86-64)

However, a strings /lib/x86_64-linux-gnu/libc.so.6 | grep GLIBC_ shows

GLIBC_2.2.5
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
....

Any idea, what I might be missing here?
Thanks in advance.

YAJSW ('Yet Another Java Service Wrapper') is an alternative for Tanuki JSW. It is under licensed under Apache License, which IMHO is a benefit over JSW.

Therefore, I think it would be helpful if appassembler could support YAJSW for its Linux daemon and Windows Service generation functionality.

http://yajsw.sourceforge.net/

When I generate-daemons I want to change the directory of the scripts to the root instead of in a bin dir.

It appears that the BASEDIR is hard coded like this:

# discover BASEDIR
BASEDIR=`dirname "$0"`/..
BASEDIR=`(cd "$BASEDIR"; pwd)`

The BASEDIR gets set to the level above the location of the script. This makes sense when you are in bin but not if you are in the root or even if you are in a nested dir.

BASEDIR should be configurable.