Implement support for click-thru license approval in quicksetup. A new panel will show up to present the license if the license file Legal/license_to_accept.txt exists in the layout. Otherwise, quicksetup will have the same behavior as before.

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

This commit is a step toward getting OpenDS internationalized. There are still issues to be resolved before we can declare that we are internationalized but this commit covers the bulk of changes needed at this time. In general this commit converts any string values that might potentially be shown to an end user (client or administrator) to a new class called Message. This includes exception messages, error log messages, alert and email text, labels, and CLI output. Message's main interface includes methods for rendering itself as a string in the default locale using toString() or a specified locale toString(Locale). In addition to addressing localization, this would allow us to potentially support controls allowing clients to set a preferred locale for server communication or output log messages in different languages. Message extends CharSequence so it can be used in some places where strings are currently used with not code change (e.g. writing to a buffer) as well as allowing messages to be composed of one another. In order to create localized messages, instead of adding them to the *Messages.java class, you define them in the corresponding properties files. In general the property file keys are used to derive the new messages severity, category, and ordinal. There are directives that can be used in the properties file in order to avoid doing this however. For instance all the properties files used internally include the 'global.category' directive at the top of the file that instructs the generator to make all the following message belong to a single category. So for internal messages the property value key will be as follows: [SEVERITY]_[DESCRIPTION]_[ORDINAL] See the properties files themselves for more information. Once your messages are in the properties file you can use the ant target 'generatemessages' to create create MessageDescriptor objects that are referred to in the Java code. In the code you might think of these objects as replacing the int-valued message IDs. To create messages you call MessageDescriptor.get() which replaces MessageHandler.getMessage(). It might be helpful then to try to define your messages before referring to them in your code since until you run 'generatemessages' you won't have any Java-code with with to create your message objects. In order to support non-localizable text in messages (host names, DN's, etc.) Message's can be created from String values by calling Message.raw(String). In this way it is also possible to circumvent the intention of changing the APIs to use Message objects instead of Strings which is to support writing of localizable messages. This method is currently used in the code as a crutch for areas of the code that need internationalization (tagged with a 'TODO: i18n' comment). It might also be used by 3rd party developers that don't intend to localize their products. However for internal use we should not be using this method to create Messages for text that is locale sensitive. Additionally this code includes a MessageBuilder that can be used in much the same way that a StringBuilder can be used. It has a method toMessage() that can be used to generate a message object when needed. At this time this method just converts the buffer contents to a raw, unlocalizable message so this will need to addressed in the future. Some other issues: - While all of the unit tests pass after this commit, there may be issues in the code where we have no or minimal test coverage. This includes much of the setup and GUI tools packages for which I have not done any testing but will begin after this commit. - The new message related Java sources are contained in package org.opends.messages and organized in a new module src/module modeled somewhat after the admin module: src/messages/src (non-generated Java source files) src/messages/generated (generated source files) src/messages/messages (properties files for messages) If you run the code from within your IDE you will have to mark all messages/src, messages/generated and messages as source directories. - To generated the MessageDescriptor files you invoke the 'generatemessages' target. - If you run the code from within your IDE you will probably ne - This commit would change the plugin API. Here are the changes caught by DirectoryServerPluginTestCase: doShutdown(String)->doShutdown(Message) doPostDisconnect(PostDisconnectPluginResult,ClientConnection,DisconnectReason,int,String) -> doPostDisconnect(PostDisconnectPluginResult,ClientConnection,DisconnectReason,Message); - This commit aligns the entire code-base behind the new Formatter class (printf style formattings like %s) as opposed to the older MessageFormat style (using curly braces for message arguments). This allows us to provide more type safety for message arguments. So for instance you can include a %c argument specifier in your format string and the MessageDescriptor will enforce specification of a Character as message creation time. - Not all of the config framework has not been converted to use Messages. Perhaps as some point we might have a 'message' syntax for locale-sensitive textural data. I'm sure Matt will have ideas about this. - In addition to Message, MessageDescriptor and MessageBuilder, the org.opends.server.message package includes enums for Category and Severity that replace the definitions formerly found in MessageHandler. - The interface for the ErrorLogger has been simplified to allow logging of messages using a single Message parameter. The severity and category of the message will be derived from the Message itself instead of specified as arguments when a message is logged. - I will provide more documentation about this plumbing on the Wiki shortly. - I will expand on the included tests soon.

The following modifications have the following goals: 1. Provide a fix for the GUI part of issue 1894 (consider replication in uninstall). Basically the graphical uninstall checks whether there is an ADS defined and if the server is configured for replication and asks the users whether (s)he wants to remove the references to the server that is being uninstalled. 2. Fix some minor issues that appear in the merged version of the installer and upgrader. 3. Update the build so that statuspanel.jar disappears. The idea is to minimize the number of jars that we have. This is a requirement coming from customers and approved by Neil in a conversation we had a while ago. 4. Minimize the number of classes that go to quicksetup.jar so that its size is the minimal possible and we reduce the download time when launching the WebStart based tools. This has been done by moving the uninstaller tool to OpenDS.jar (with the status tools).

This commit's design changes have been reviewed and approved by Brian Ehret. Add a "Finish" step to the graphical upgrade, setup and uninstall. Issue 1325: Update quicksetup to integrate common install scenario These modifications allow to configure replication in the graphical setup. Issue 1850: consider replication for uninstall and cancel install These modfications allow to cancel the modifications done in remote servers during the install when the user clicks on cancel. Issue 1863: combine Web Start upgrade and install into one tool These modifications allow to launch an application that combines both install and upgrade. Note: because of some problems with the total update (see Issue 1893) the administration suffix is configured with its own database so a new directory has been created in the installation (adminDb). If we consider that is not a good idea to have a separate database this will be updated in the future once 1893 is fixed. The directory must be created during installation because in some case the Administration configuration is created using LDAP and remotely when installing a new server (and in this case we have no access to the fiel system of the firstly installed server).

This commit addresses issue 1599 as well as introduces some other changes suggested by Brian after reviewing the SWAED guidelines: - Changes how buttons appear for the install, uninstaller and upgrader. The Cancel button has been moved from the ButtonPanel to the ProgressPanel along side the progress bar for applications that are cancelable. Right now this only includes the upgrader. The installer before this commit allows the user to press a Close button which prompts the user before exiting. However the installer leaves its files behind currently when canceled so I have not implemented the 'cancelable' code as part of this commit. With this commit the installer just displays a disabled Close button while running which is enabled after progress stops (like the uninstaller). - All applications now display a disabled Close button at the bottom which becomes enabled after the progress has finished or been canceled. - Adds the Launch Status Panel command button to the final screen for the upgrader. - Changes the end state inline alert from error to info when an upgrade is canceled.

This commit addresses several issues that Brian brought up regarding the upgrader. - Lots of label, dialog wording and layout changes. - The user is now warned if they try to close the upgrader window before it is finished. If the user indicates they want to cancel the operation the upgrader cleans up any filesystem changes that had been made to that point. - Added ability for progress panel to display HTML pre-formatted error messages as is currently possible for success messages.

enough code to get the upgrader to perform a successful upgrade in graphical UI mode on a sunny day

This commit introduces preliminary versions of the upgrader tool's GUI wizard panels. Effort has been made to make the panels conform to the design at http://bde.central/projects/opends/www/public/docs/ui-docs/specs/updater.html As of now the panels are pure presentation as they do not display/edit any real data. This commit also introduces a number of refactorings of the quick setup GUI wizard classes: - Made createLayout() a private method that is called during initialize() rather than the constuctor of each child application. In general I don't like constructors that do lots of work beyond initializing variables since you can override behavior. I've also added GuiApplication as a parameter to QuickSetupPanel since it can provide panels with any state information that the panel need to present. - Moved QuickSetup to the ui package since its purpose is representing quicksetup GUI applications. - Made ReviewPanel abstract so that other applications could share the layout code.

- The upgrader now contains a small companion program BuildExtractor that is run prior to Upgrader that extacts the user specified build file. This is done to allow upgrader to run from the new builds bits as opposed to the current build's bits. - Improved error notification

- Succeeded in removing the Utils.isUninstall() method. All the logic that was being controlled by if statements using this method has been moved to the applications themselves (except for a few hacks that I've documented in the code) - Abstracted a new WizardStep class from the Steps class which is still being used by the installer and uninstaller. As some point we might want to separate the installer steps and uninstallers steps but I didn't do this now.

Update all CDDL headers in source files to remove a typo.

This removes old debug logging framework method calls that are going to be automatically instrumented by AspectJ. Non instrumented debug method calls are updated to use the new debug framework methods. However, the new debug logging framework is not yet active as the Aspects are not weaved in. After this revision, debug logging will be disabled in the server until the new AOP framework is complete. - Removed debugEnter and debugConstructor from all source files. - Removed CLASS_NAME static string for debug purposes. - Removed old debug logging framework. - Added new debug logging frameworking using AOP. - Added AspectJ binary and libraries. - Change all modified files copyrights to include 2007.

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 <install-root>/lib/quicksetup.jar and <install-root>/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.

The modifications basically do the following: * Add a new quicksetup.jar file that can be used for both Web Start and local installations of Open DS. * Modify the setup script so that now they will launch by default the graphical setup. If an error occurs (because for instance we do not have access to the display) or if the user specifies the --cli option then we will use the cli based setup (the one we had until today).