<?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 Makefile</title>
    <link>http://src.iws.cs.ovgu.de/source/rss/forgerock/opendj2/src/build-tools/windows/Makefile</link>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2005</copyright>
    <generator>Java</generator>
    <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/src/build-tools/windows/Makefile - 0f8553e2af5fc49a510ecfcfc93e66d06713f631</description>
        <pubDate></pubDate>
        <dc:creator>ludo</dc:creator>
    </item>

    <item>
        <title>Fix OPENDJ-161 - Rebranding Windows service integration to OpenDJ</title>
        <description>/forgerock/opendj2/src/build-tools/windows/Makefile - 998dba1a6a977079f1f5d9ad99ca8818d7f74623</description>
        <pubDate></pubDate>
        <dc:creator>ludo</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/src/build-tools/windows/Makefile - a395dd575518d9e5280fc5d5d5ef47c61b174647</description>
        <pubDate></pubDate>
        <dc:creator>ludovicp</dc:creator>
    </item>

    <item>
        <title>Fix for issue 1603 (quickInstall fails to register service on vista)
    
    With the new user access control of Vista, even if we are administrators we are not allowed to do certain operations (such as writing in the service registry) in some circumstances.  For instance if we launch net start &lt;service_name&gt; from a normal command prompt this will fail systematically.  In order to be able to execute these "privileged" operations we have different alternatives:
    
    Execute the binary that will do the operations using the "Run as Administrator" option in Vista (or launching them from a command prompt that has been started using that same option).
    Add a manifest to the binary informing that the binary requires administrator privileges.
    
    The first alternative is one of the workarounds for the bug, however it does not apply to the case of the Java Web Start Installer.
    
    The second alternative is in what consists the bug fix.  A new binary has been created.  This binary has a manifest informing that it requires administrator privileges.  This binary will be used in Vista as a wrapper to call operations that require administrator privileges (modifying the registry in windows-services.bat command line and calling "net start" and "net stop").
    
    If the user is running the setup, the status-panel using the "Run as Administrator" option or is using the command lines from a command prompt launched with that option the behavior in Vista does not change with the behavior in previous versions of Windows.
    
    If the UAC is enabled and the user is not using the "Run as Administrator" options, (s)he will be prompted for confirmation each time the registry is modified and the server is started or stopped as a service.  The wrapper is called on any of the individual operations.  An alternative would be to call the wrapper when we launch the setup or the status-panel but this generates some issues:
    1. This does not work (directly) with the Java Web Start installer.
    2. This would force users that are not administrators to provide administrator credentials even to install/run an OpenDS that does not require to do privileged operations (an OpenDS that does not run as a service).</title>
        <description>/forgerock/opendj2/src/build-tools/windows/Makefile - 797b7557ad71a61ffb72a68f4457a3d999e7e252</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Make several significant changes to the OpenDS code base, including:
    
    - Narrow down the set of packages that external developers will need to access
      in order to write a plugin or other type of extension.  Hopefully, for most
      things developers will only need to interact with the following packages (and
      their sub-packages):
      * org.opends.server.admin
      * org.opends.server.api
      * org.opends.server.config
      * org.opends.server.protocols.internal
      * org.opends.server.types
      * org.opends.server.util
    
    - As part of the attempted narrowing of packages that external developers need
      to access, I have moved the org.opends.server.core.Operation and
      org.opends.server.protocols.ldap.LDAPException classes to the
      org.opends.server.types package.  I have also created
      org.opends.server.types.RawAttribute to wrap the
      org.opends.server.protocols.ldap.LDAPAttribute class, and
      org.opends.server.types.RawModification to wrap the
      org.opends.server.protocols.ldap.LDAPModification class.
    
    - I have updated the internal operations API to add a few new convenience
      methods when performing internal operations.
    
    - I have updated all of our message strings so that none of them end in periods
      (except those that end with an ellipsis).  This will help us avoid the
      problem in which we see multiple periods due to embedding one message in
      another.
    
    - I have moved a message file from a synchronizaiton package to the messages
      package and resolved conflicts with existing message IDs.
    
    - I have updated a number of cases in which
      StaticUtils.stackTraceToSingleLineString() was used in client-facing code to
      replace those calls with StaticUtils.getExceptionMessage() instead.  This
      should provide a more user-friendly message that will hopefully not reduce
      our ability to debug problems that may arise.
    
    - I have cleaned up some of the code in the org.opends.server.api package so
      that all of the classes use consistent formatting, and to fix a couple of
      potential Javadoc problems.
    
    - I have moved the build-tools/src directory to src/build-tools to be more
      consistent with other components of the server.
    
    - I have updated the build script so that the xslt task will no longer dump
      lots of output to the terminal when generating code.  I have also gotten rid
      of warnings about run.classpath not being set properly.</title>
        <description>/forgerock/opendj2/src/build-tools/windows/Makefile - 99faa045b6241c1d2843cce1b7a9d9c97055beae</description>
        <pubDate></pubDate>
        <dc:creator>neil_a_wilson</dc:creator>
    </item>

</channel>
</rss>

