<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/source/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in setup</title>
    <link>http://src.iws.cs.ovgu.de/source/rss/forgerock/opendj2/resource/setup</link>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2005</copyright>
    <generator>Java</generator>
    <item>
        <title>setup: Added SCRIPT_ARGS environment variable to allow debugging like any other CLI programs</title>
        <description>/forgerock/opendj2/resource/setup - c81cbcca08ea7ebca62e65196dbfb3d82df7d35d</description>
        <pubDate></pubDate>
        <dc:creator>JnRouvignac</dc:creator>
    </item>

    <item>
        <title>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.</title>
        <description>/forgerock/opendj2/resource/setup - 0f8553e2af5fc49a510ecfcfc93e66d06713f631</description>
        <pubDate></pubDate>
        <dc:creator>ludo</dc:creator>
    </item>

    <item>
        <title>Fix 3534: Provide native Solaris packages (fix also 3533: upgrade fails starting server adding entry ds-cfg-key-id)</title>
        <description>/forgerock/opendj2/resource/setup - d319724fed3be916a9f68676aac6eb203d44b551</description>
        <pubDate></pubDate>
        <dc:creator>chebrard</dc:creator>
    </item>

    <item>
        <title>These changes are separating the current delivery into
    an "Install Layout" (the binaries) and an "Instance Layout" (the user data).</title>
        <description>/forgerock/opendj2/resource/setup - 014019918f7e3844f558f6159b8d41517254edc2</description>
        <pubDate></pubDate>
        <dc:creator>lutoff</dc:creator>
    </item>

    <item>
        <title>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.</title>
        <description>/forgerock/opendj2/resource/setup - 3cedecd5ea21cca5d9709abf320a2082cd3694e5</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Updated the copyright statement to reflect that Sun owns the full copyright on the project files.</title>
        <description>/forgerock/opendj2/resource/setup - a3d3ab94806056d2355afea6fe8daac41059b9fb</description>
        <pubDate></pubDate>
        <dc:creator>ludovicp</dc:creator>
    </item>

    <item>
        <title>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.</title>
        <description>/forgerock/opendj2/resource/setup - 27f8adec83293fb8bd3bfa37175322b0ee3bb933</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Fix for issue 2035 (Use OpenDS specific environment variables to determine the JVM to be used.)
    
    Use two environment variables to know which is the JVM to be used by the scripts: OPENDS_JAVA_BIN and OPENDS_JAVA_HOME.
    
    When the setup creates the file lib/set-java-home it writes the contents of OPENDS_JAVA_HOME to it (instead of JAVA_HOME which was the previous behavior).
    
    Before these changes, the scripts used to look for JAVA_BIN, then JAVA_HOME and finally for the contents of the set-java-home file.  The problem with this approach is that if the user required to specify JAVA_HOME or JAVA_BIN to an unsupported version of the JDK (because some other program in the machine had this requirement) the scripts of OpenDS could not run.  Now the checks that we do to figure out the JVM are done in the following order:
    1. Check if OPENDS_JAVA_BIN is defined in the environment.
    2. Check if OPENDS_JAVA_HOME is defined in the environment.
    3. Check if OPENDS_JAVA_HOME is defined in the lib/set-java-home file.
    4. Check if JAVA_BIN is defined in the environment.
    5. Check if JAVA_HOME is defined in the environment.
    6. Check if we can figure out the java installation by executing "type java" (in UNIX environments).
    
    If any of the above checks is positive, we will try to use the JVM found.
    
    Extras: the uninstall script on UNIX now checks that we are using a JDK compatible with 1.5 and displays a user friendly message if it does not.</title>
        <description>/forgerock/opendj2/resource/setup - 37f9a536593b696e5a3dcec443e1475f22fb5afd</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>After some discussions it has been decided to merge the setup and uninstall commands so that we have the behavior that we had before.  So with this changes, in order to work in CLI mode the option --cli must be specified.</title>
        <description>/forgerock/opendj2/resource/setup - b26e36d8a08a1c775531659c04abc3d4ed504139</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>The following changes are targetted to fix a certain number of issues related to the setup command line:
    
        * 1257 setup cli/gui symetry -- allow to start after slient install
        * 1264 silent install option is not silent
        * 1326 Update setup CLI to integrate common install scenario (partial fix)
        * 1404 different CLI/GUI behavior running setup
        * 1859 spin off GUI specific CLI commands
        * 2184 setup quite/no-prompt
        * 2185 setup --cli -Q throws error
    
    The changes basically consist on splitting the current setup command-line into two (the same way we have done for the uninstall). Know we will have one command to launch the setup in CLI mode (setup and setup.bat) and one command to launch the setup in GUI mode (setup-gui and setup-gui.bat).
    
    The behavior of the graphical interface has not changed. However the capabilities of the CLI setup have been extended to allow to match those in the graphical interface (excluding the replication configuration capabilities):
    
        * Configure the LDAPS and StartTLS on the server.
        * Start the server.</title>
        <description>/forgerock/opendj2/resource/setup - a37d24d06e3d85017b59997302b89bc2017b0970</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>fix for issue #1865 (upgrade -V error)
    In case on -V option, BuildExtractor will exit with a pre-defined return code defined in QuickSetupCli.java (let's say 50). Script will test this specific return value to check if the non-null return code is an error. In case of none null return code, the upgradeLauncher will not be called.</title>
        <description>/forgerock/opendj2/resource/setup - da7ab15aee42edf1c4ff33f66ca717f019b4a578</description>
        <pubDate></pubDate>
        <dc:creator>lutoff</dc:creator>
    </item>

    <item>
        <title>Complete fix for 1252 restrict installed bin files to relevant platform.
    
    The bat files are only under 'bat' directory and some function scripts that are not targetted to be used by the user (_server-script, _client-script, etc.) have been moved now to lib.</title>
        <description>/forgerock/opendj2/resource/setup - 9da44d3de0a7180285a77b7e8d2426a72aca249e</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Fix for issue 1273 (exception if JAVA_HOME undefined in scripts).
    
    The fix consists of modifying the scripts to launch the InstallDS classwith a test option using the JVM that was found.  If the JVM can be successfully launched, the JVM is compatible with 1.5, if not we as sume that is not compatible with JDK 1.5.
    
    The downside of the fix is that it requires an additional start of the JVM each time the command line is launched. That is why the fix only applies to setup, uninstall, upgrade, start and stop command lines.  The modifications in _server-script.* and _client-script.sh just modify the message displayed when a JVM could not be found (informing that JDK 1.5 or later can be used).</title>
        <description>/forgerock/opendj2/resource/setup - ef629cb5106ea89a04c63677373c4d70b099e053</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Update all CDDL headers in source files to remove a typo.</title>
        <description>/forgerock/opendj2/resource/setup - f71f7a61dec7c9089378d14493ad564a1dedf0b5</description>
        <pubDate></pubDate>
        <dc:creator>neil_a_wilson</dc:creator>
    </item>

    <item>
        <title>The following modifications include the comments from Neil and Brian (thanks to both for your help):
    
    1. Fix a bug with the setup script.  Know this script is executable after the Web Start based installation.
    
    2. Provide a different welcome message in the setup depending on whether we are launching the setup from the command line or Web Start.  If we are launching the command line setup we make reference in the message to the Web Start installation and provide a link to the downloads page.
    
    3. When the setup is successful, include in the message the path of the installation as was requested by William Hathaway.
    
    4. Try to find a valid default port  (of type []389) and not limit the search to 389.  This implies not having any explanatory message to be displayed if we cannot connect to 389.
    
    5. Update the code to better handle bug scenarii.  Previously the code assumed that only RuntimeException could occur in case of a bug.  This is not true in the general case, so know the code handles Throwable objects to detect bugs.
    
    6. Provide the first implementation for the Uninstaller.  Some code has been rearranged to maximize code re-use.  The first implementation of the uninstaller basically does the following:
    
    - Display a confirmation message informing of what will happen with the installation files and the consequences of uninstalling the server.
    
    Ask the user which parts of the server must be uninstalled.
    
    Check if we have configuration references outside the installation path (for the moment this check is limited to database files and log files). If these references exist show them to the user and ask the user whether these 'external' files must be deteled or not.
    
    If the server is running we ask for confirmation to stop the server and if we are in windows we ask the user to provide a DN and a password to authenticate.
    
    If the user continues and the server is running the code calls stop-ds script, if the script succeeds the code tries to delete the files in the installation that the user wanted to uninstall and  in the case there are external files to the installation path and the user wants to delete them delete also these external files.
    
    If everything works properly the uninstaller will delete all the files except the &lt;install-root&gt;/lib/quicksetup.jar and &lt;install-root&gt;/lib/OpenDS.jar file.
    
    OpenDS.jar file is required by the command line uninstaller to share some code.
    
    I preferred not to try to delete these files from the scripts as we cannot provide proper feedback (for instance localization) if we encounter a problem deleting these files.
    
    In both cases we inform the user that there are some files that must be deleted manually.
    
    7. Provide the code to launch uninstall through command line that is analogous in terms of interaction to the graphical one.
    
    I have included two scripts to launch the uninstallation.  The uninstall script for Unix is very similar to the setup script.  However the uninstall.bat script has a difference with setup.bat.
    
    The difference is that I limit the class path to include only quicksetup.jar.  This is done because I have not found a way to delete the jar files that are in the class path of the java application using pure java code, so as the uninstaller does only require OpenDS.jar and quicksetup.jar files I have chosen to minimize the jar files in the class path.
    
     This way the only files that are not deleted during installation is quicksetup.jar and OpenDS.jar.
    
    8. Improve the wording of the install wizard as proposed by Brian and Neil.
    
    9 . One minor tweak to the QuickSetup Welcome screen: make the reference to the "setup" command a monospace font to highlight it a bit more.
    
    10.  Fix for issue 1057  (stop-ds.bat and start-ds.bat do not work when called using Runtime.exec).  The quicksetup code used to overwrite the environment variables when calling Runtime.exec which made the server not be able to start/stop correctly.
    
    11. Fix some minor bugs with the default focus on some panels.
    
    12. Update the setup scripts to use the java home file if the setup was previously called.</title>
        <description>/forgerock/opendj2/resource/setup - c9d984b0d2c0fda320e79eb3868dd6fbeb1ffa34</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Rename the "setup.sh" script to "setup" and update all references to it to use
    the correct name.
    
    OpenDS Issue Number:  993</title>
        <description>/forgerock/opendj2/resource/setup - 530a10a76564724578a42c8e164d6bf645faee85</description>
        <pubDate></pubDate>
        <dc:creator>neil_a_wilson</dc:creator>
    </item>

</channel>
</rss>

