OPENDJ-842 (CR-1699) On Windows, the setup command hangs when the length of the install path is too long In order to avoid getting errors like "The input line is too long" on windows, a common way to fix this is to provide a "bootstrap" empty jar which contains only a MANIFEST.MF file listing all the application's jars in the "Class-Path" attribute. This URL describes well enough the problem: http://ant.apache.org/manual/Tasks/manifestclasspath.html build.xml: In "prepackage" target, build bootstrap.jar. _script-util.bat, _script-util.sh: Replaced appending all the jars under libs with just the bootstrap jar. Utilities.java, Utils.java, UpgradeUtils.java: In getInstallPathFromClasspath(), extracted getInstallPath() and simplified its code a lot. Installation.java, Installation.java: Changed OPEN_DS_JAR_RELATIVE_PATHS into OPEN_DJ_BOOTSTRAP_JAR_RELATIVE_PATH.

svn merge https://svn.forgerock.org/opendj/trunk/opends@8851 https://svn.forgerock.org/opendj/branches/native-packaging@8851 .

Fix for OPENDJ-222 : Renamed environment variables to OPENDJ_... Updated scripts so that if OPENDJ_JAVA_HOME and OPENDJ_JAVA_ARGS are not defined, we look at the legacy OPENDS_... ones.

Add support for SVR4 packages for OpenDJ. Package name is opendj. It's a single package and has integration with SMF. Default installation is /usr/opendj. Once packages are installed, root must run configure to setup the Instance location (/var/opendj) and owner. And the owner must run setup.

Removed invalid Break statements in case block

Improve error message for required version of Java runtime

Cleanup. Remove references to Java 5 since we no longer support it. Cleanup messages, removing unnecessary casts (due to bugs in early versions of Java 5), removing dead code. The minimal version has been set to Java 1.6.0_10. Also cleanup the Java Stubs for MacOS, removed the StatusPanel (replaced by ControlPanel since 1.2), and update Info.plist to require 1.6 or higher, show 2.3 as version.

Fix for issue 4489 (java is not detected even if the JAVA_HOME variable is defined)

Fix for issue 4362 (failure to detect properly installed Java) The fix consists on two parts: 1. Give priority to the java binary set in the path (which is usually updated when java is installed). 2. Check that actually the java binary found in the environment variables does exist.

Fix for issue 4332 (Tools fail when instance path contains whitespace) The problem is in the code in charge of checking the install and instance paths and contents. There are issues both in the scripts and in the code of org.opends.server.tools.configurator.CheckInstance. Using quotes fixes the issue in the script and using an array of String instead of a single command-line to launch the "ls" process. Apart from that some error messages have also been fixed.

Fix ServiceTag URN for 2.0 Fix ServiceTag Registration adding debug message in case of error Fix 2619 : ldap tools always return 1 in case of argument parsing error Fix 3690 : SNMP: incorrect value for dsServerDescription entry Fix an error in the util script when the install dir is != instance dir

Fix for issue #3626 (Occurrences of grep, cat,... commands should be replaced with sh built-in commands) Replace occurrences of 'cat' and 'grep' by shell builtin command.

Use 'Java' instead of 'java' in the messages.

- fix typo.

Fix 3798: Unable to use more than 50% of machine memory for server JVM settings were used by scripts when checking the validity of the instance. This modification removes the use of the JVM setting during the bootstrapping phase. This fixes the following issues: * if JVM is configured for the server instance suspends on start up for debugging, the server suspends during the bootstrapping phase rather than when the real server instance has started. (remaining issue related to issue 3711) * if the JVM is configured to use more than around 45% of the machine's memory, we run out of memory (issue 3798)

Fix for issue #3802 (script launcher return codes are not correct) we now unify _script-util.sh return code: we return 0 (success) or 1 (error). Additional error messages have been also added in order to send a better feedback to the user.

Fix file sepator in the licenfile Update the classpath wit hadditional resources

Frontport of all fixes related to SVR4 from branch 1.2 to trunk: 3646 configure script fails to retrieve the user/group of the ins 3647 Missing license file 3648 Third party license files should be merged 3649 Wrong copyright file in SVR4 package 3650 LDAP tools are missing in SVR4 package 3651 Server is not stopped after package removal 3654 SVR4 pkginfo not compliant with Solaris rules 3658 no man pages in SVR4 package 3661 SVR4 only: OpenDS fails to start with 1.1.0 bld3 3663 SVR4: unable to start OpenDS if user has no home directory 3664 SVR4: delimiter used in copyright file is not the one define 3706 configure: configure -H/-V doesn't work when the instance is 3707 unconfigure: unconfigure --wrongoption should display the us 3708 stop-ds: stop-ds -R doesn't work 3729 incorrect exit codes for configure/unconfigure scripts 3735 OpenDS failed to start if build number contains version qual

Fix 3711: Unable to remotely debug the server CheckInstance no longer calls 'start-ds -F' but uses same classes as start-ds to generate the version of the install dir. Move the configurator package from src/quicksetup to src/server/tools.

LP: location of instance.loc file for SVR4 pkg is now /etc/opends/. Reference was updated, but the ones in this file were missed.

Fix issue 3607

Fix 3548: perf regression in OpenDS between rev 4539 and rev 4548

Fix 3534: Provide native Solaris packages (fix also 3533: upgrade fails starting server adding entry ds-cfg-key-id)

These changes are separating the current delivery into an "Install Layout" (the binaries) and an "Instance Layout" (the user data).

Second part of fix for issue 3126 (Cannot run setup if unziped in directory with spaces in name). These changes allow to execute the scripts from different directories than the one the script is located at.

Fix for issue 3126 (Cannot run setup if unziped in directory with spaces in name) Fix the script to be able to handle paths with spaces in the classpath.

Fix for issue 2444 (Commands setup/start/etc... should check Java release and reject unsupported ones) The script-util.sh test java functions now also handle the case where we have a non supported 1.5 version of the JDK.

Updated the copyright statement to reflect that Sun owns the full copyright on the project files.

The following one-line commit avoid problems in the case the user modifies set-java-home (or we keep an old set-java-home). If calling set-java-hme does not set OPENDS_JAVA_BIN, just try to figure it out from the environment (instead of assuming that set-java-home will do that *always*).

2730: New - The setup command should perform some basic memory tuning Note: this issue is not fully covered by the proposed modifications but all that is missing in order to fix it is to figure out which are the default memory values that we want to propose in the setup. 2620: Server should be started as server JRE and clients should be started as client JREs The proposed solution goes beyond fixing the two issues and proposes a manner for the user to set specific java arguments (and use a specific JVM) for every command-line. Today the user can specify the JVM to be used using the OPENDS_JAVA_HOME environment variable and the java arguments by using the OPENDS_JAVA_ARGS environment variable. In the case of the JVM this covers most of the use cases (in general we will use the same JVM for all the command-lines). However this is quite limiting in the case of the java arguments we pass. For instance in general we want to run the server (start-ds command-line) using the server mode of the JVM but other command-lines using the -client mode of the JVM. In the same manner we might want to have a bigger heap when running the server than when we are running a "lightweight" utility as dsconfig. The proposed solution is to have a properties file called java.properties where the user specifies the different JVM and java arguments to be used for every command-line. Once the user has edited this properties file, (s)he must run a command-line called dsjavaproperties that will update all the scripts to use the arguments specified in that properties file. NOTE: there are a number of command-lines (import-ldif, export-ldif, backup, restore) where the user will be able to specify different java arguments (and different JVM) to use depending on whether the command-line is run in online or offline modes. You can see the comments on java.properties to get more information about this and in general about the different properties that can be set. The modification in the setup basically try to check if the JVM that is being used to run the setup (the one that will be used by default) supports the -client and -server options. Depending on the results of these checks the setup will update the java.properties file and then run dsjavaproperties to update the scripts.