This Blog Has Moved

I'm shutting down this blog and moving everything to my main site, https://nawilson.com/. At some point in the near future, I'll redirect the dirmgr.com domain to nawilson.com so that clients going to the old site will find the new one, but RSS feeds looking at this site may not continue to work.

If you're primarily interested in LDAP and identity management content and not my other stuff (especially writing about movies), you can find that directly at https://nawilson.com/category/ldap/, and you can subscribe to updates via RSS at https://nawilson.com/category/ldap/feed/.


Important updates about the upcoming 4.0.0 release of the UnboundID LDAP SDK for Java

TL;DR: The next release of the UnboundID LDAP SDK for Java will have a version number of 4.0.0, will require Java SE 7 or later, and there will be just one edition instead of the three editions that we currently maintain.

Although it’s still at least a month or two away, I wanted to make a couple of announcements about the next release of the UnboundID LDAP SDK for Java that might affect some of its users. These are some significant changes, so we’ll bump the version number to 4.0.0.

We’re going to start updating the LDAP SDK to reflect these changes immediately, but there’s still time before the release, so if you do have any concerns or questions about these changes, then now is the time to raise them. The best way to do that is to send us an email at ldapsdk-support@pingidentity.com. or use the SourceForge project discussion forum.

Requiring Java SE 7 or Later

The first change is that we’re going to require Java SE 7 or later to use the LDAP SDK.

All previous LDAP SDK releases have been compatible with Java SE 5.0 or later, but Java SE 5 is really old. According to http://www.oracle.com/technetwork/java/eol-135779.html, Oracle stopped providing public updates for it in 2009, and even extended support for it ended in 2015. There are a few things in the SDK that don’t work as well if you’re using Java SE 5, and for which we currently have to use reflection to access on newer VMs.

Dropping support for Java SE 5 allows us to simplify that code and potentially take advantage of new Java features that were added in Java SE 6 and 7. We’ll also be able to update some components that we use during the LDAP SDK build process, although this doesn’t have any impact on your ability to use the SDK. And as always, the LDAP SDK does not and will not depend on anything except Java SE, so you won’t need any third-party libraries to use it.

The older releases of the LDAP SDK aren’t going away, so if you really need to run on Java SE 5.0 or 6 for some reason, then you can continue to use one of the existing releases.

Only Releasing a Single Edition

Another notable change is that we’re only going to be providing a single edition of the LDAP SDK moving forward. Right now, we offer three editions:

  • Standard Edition (SE) — A fully-functional LDAP SDK for use with any type of LDAPv3 directory server.
  • Commercial Edition (CE) — Everything in the Standard Edition, plus additional features specifically intended for use in conjunction with the UnboundID/Ping Identity Directory Server, Directory Proxy Server, and other server products.
  • Minimal Edition (ME) — A very stripped-down version of the LDAP SDK that still provides core LDAPv3 support, but with a focus on keeping a very small jar file for space-constrained environments like Android or embedded systems.

Offering a separate Commercial Edition of the LDAP SDK was necessary in the past because it wasn’t open source and we only made it available to customers who had purchased our server software. But since then, we made it open source and publicly available. There were also concerns about a developer accidentally writing code that leveraged proprietary features that would prevent it from working against non-UnboundID/Ping Identity servers, but that’s easy enough to avoid by just staying away from classes in a package below com.unboundid.ldap.sdk.unboundidds.

Similarly, in the earlier days of Android and other Java-based embedded systems, you didn’t have as much room to work with as you do today, so having a Minimal Edition with a significantly smaller footprint was useful, but it did come at the cost of functionality and convenience. And even the Commercial Edition isn’t all that big (the jar file is around 3.5 megabytes, versus 650 kilobytes for the Minimal Edition, and two megabytes for the Standard Edition).

So from now on, we’re just going to have one edition, and we’ll just call it UnboundID LDAP SDK for Java. It’ll have everything in it that the Commercial Edition has, and it’ll continue to be open source under the terms of the GPLv2 and LGPLv2.1 (plus the UnboundID LDAP SDK Free Use License, which isn’t open source but lets you use and redistribute the LDAP SDK for just about any purpose as long as you don’t make any changes to it). The jar file will be named unboundid-ldapsdk.jar , and we’ll continue to publish it to Maven with a GroupId of com.unboundid and an ArtifactId of unboundid-ldapsdk.


LDAPv3 Wire Protocol Reference

I've just published a new LDAPv3 wire protocol reference, with an in-depth look at how LDAP messages are encoding, with plenty of annotated examples. It's available at https://nawilson.com/ldapv3-wire-protocol-reference/.


Understanding and Defending Against LDAP Injection Attacks

The subject of LDAP injection attacks has come up a couple of times recently, so I wrote a post about them. It's available at https://nawilson.com/2017/03/22/understanding-and-defending-against-ldap-injection-attacks/.


LDAP Result Code and OID Reference Guides

I’ve added a couple of LDAP reference documents.

The LDAP Result Code Reference provides a fairly complete overview of many LDAP result codes, including the core LDAPv3 result codes defined in RFC 4511, server-side result codes from other specifications, and client-side result codes. It describes each of the result codes and some of the cases in which they may be used.

The LDAP OID Reference lists a number of object identifiers used throughout LDAP for things like schema elements, controls, and extended operations. It lists the OIDs, provides a brief explanation of its purpose, and, when applicable, provides a link to the relevant specification.

Both of these will also be included in the documentation for the next release of the UnboundID LDAP SDK for Java (and they’re already checked into the GitHub repository), but for now, you can find them on my website.


A Couple of Updates to the LDAP SDK Open Source Repository

Within the last weeks, there have been a couple of noteworthy changes to the open source repositories for the UnboundID LDAP SDK for Java.


Migrated the GitHub Repository to Ping Identity

The primary open source repository for the LDAP SDK is on GitHub. It used to be part of the UnboundID organization, but over the weekend, I migrated it to the Ping Identity organization (since Ping Identity acquired UnboundID last year). The new URL for the LDAP SDK project on GitHub is https://github.com/pingidentity/ldapsd.

This should be a completely transparent migration. All of the content (revision history, releases, issues, forks, etc.) should have been preserved. The URLs used to access the repository have changed, but GitHub should redirect all of the old URLs to the new ones, so if you have any links or bookmarks that use the old URLs, you should still end up in the right place. This is also true for any clones of the repository, but if you have checked out the LDAP SDK, then you might want to update your local workspace to the new path. You can do that with the command:

git remote set-url origin git@github.com:pingidentity/ldapsdk.git

If you notice any problems with the repository as a result of the migration (or for any other reason), please open an issue, and we’ll look into it.

And for the record, we also migrated the other public UnboundID repositories to Ping Identity. That includes account-manager, auth-explorer, auth-ui, broker-groovy-sign-in-sample, broker-react-sign-in-sample, my-account, scim, scim2, server-sdk-maven>, and status-servlet.


Published the LDAP SDK Unit Tests

When we originally made the LDAP SDK open source, we published everything that you need to build the LDAP SDK, but there was some content from our internal repository that wasn’t made public. The biggest omission from the open source repository was the set of unit tests.

The main reason for omitting the unit tests was that, at the time, most of them required the UnboundID Directory Server (now Ping Identity Directory Server), and that wasn’t publicly available. It was possible to run the tests without a Directory Server instance, but there would be large portions of the code that wouldn’t get covered. But then we updated the LDAP SDK to include the in-memory directory server, and we started using it for most unit tests created after that, so now you can get really good test coverage without an external Directory Server instance.

There are still some tests that will only get run if you have an external Directory Server instance, and if you want to run them, you can download the 6.0.1 release of the Ping Identity Directory Server from https://www.pingidentity.com/en/products/downloads/pingdirectory.html. You’ll need to create an account if you don’t already have one, but that’ll get you access to a free, fully-functional evaluation copy of the Directory Server. The license doesn’t allow you to use the Directory Server for any commercial purpose, but it’s certainly suitable for use in running the unit tests if you so choose.

And with this update, the GitHub repository for the LDAP SDK is now a complete mirror of the internal subversion repository, and we expect to always keep them in sync. At some point, we may make the GitHub the master repository for the LDAP SDK, but at present, there are some internal build processes that rely on our private repository (and rely on subversion rather than git).


UnboundID LDAP SDK for Java 3.2.1

We have just released the 3.2.1 version of the UnboundID LDAP SDK for Java. It is available for download from the LDAP.com website, as well as from GitHub, SourceForge, or the Maven Central Repository. You can get a full list of changes included in this release from the release notes. The Commercial Edition release notes also provide information about additional changes only included in the Commercial Edition. Some of the most significant changes in both the Standard Edition and the Commercial Edition include
  • Updated the documentation to indicate that, as a result of Ping Identity's acquisition of UnboundID, all non-public feedback, feature enhancements, support requests, and other kinds of communication should now be sent to ldapsdk-support@pingidentity.com instead of ldapsdk-support@unboundid.com. We also now recommend using the GitHub issue tracker over the SourceForge mailing lists and discussion forums for bug reports and feature requests.
  • Fixed a bug in the RDN parsing code that could cause multiple consecutive spaces in the middle of an attribute value to be condensed down to a single space. The string representation of the RDN was preserved correctly, but the methods used to retrieve attribute values as a string or byte array could return values that were missing spaces.
  • Provided better handling for InterruptedException. A thread's interrupted state will now be preserved for cases in which the LDAP SDK consumes an InterruptedException without doing something to handle it.
  • Fixed a bug in the support for the SASL ANONYMOUS mechanism that could cause the trace string to be omitted from the encoded bind request.
  • Updated the searchrate tool to provide support for generic controls, as well as specific support for the assertion, simple paged results, and server-side sort request controls.
  • Updated the authrate tool to add a new --bindOnly argument that allows you to indicate that the tool should only perform bind operations, rather than a search to find the entry and then a bind as that user. The base DN pattern will be used to construct the bind DN.
  • Updated the authrate tool to provided support for generic search and bind controls, as well as specific support for the authorization identity and password policy request controls.
  • Updated the search-and-modrate tool to provide support for generic search and modify controls, as well as specific support for the assertion, simple paged results, permissive modify, pre-read, and post-read request controls.
  • Added a Schema.getSchema method that can read schema information in LDIF form from an input stream.
  • Updated support for the GSSAPI SASL mechanism to make it possible to indicate in the generated configuration file whether the client should act as an initiator or an acceptor.
  • Updated the identify-unique-attribute-conflicts tool to include a time limit in search requests intended to determine whether a unique attribute value may also be in use in any other entries. This can help limit the effect of running the tool against a server that is not configured with the appropriate indexes needed to ensure that equality searches targeting the unique attributes can be processed efficiently.
Some of the additional changes only available in the Commercial Edition include:
  • Added a new version of the ldapsearch tool that provides a lot of additional functionality over the version provided in the Standard Edition. It includes much better output formatting (including support for alternate output formats like JSON, CSV, and tab-delimited text), support for a number of data transformations, more robust connection handling, support for referrals, support for a large number of search and bind controls, support for administrative sessions, support for unsolicited notifications, the ability to process multiple searches with search criteria provided in filter or LDAP URL files, rate limiting, and the ability to send results to a specified output file (or a separate output file per search).
  • Implemented caching for the matching rule instance used when requesting the jsonObjectExactMatch matching rule. This matching rule only exists in the Commercial Edition and needs to be loaded via reflection.
  • Updated the access and error log parsing APIs to include support for the triggeredByConn and triggeredByOp log fields used to indicate that the message is associated with the indicated operation.

The Story of UnboundID

At the end of 2016, I ceased to be an employee of UnboundID and became an employee of Ping Identity. Ping acquired UnboundID in early August of 2016, but most UnboundID staff remained employees of that company through the end of the year (mostly for bookkeeping convenience). As a co-founder, I was with UnboundID from the beginning. Here is our story.

Once upon a time, Sun Microsystems had the best LDAP directory server on the market. The 5.1 and 5.2 releases of the Directory Server Enterprise Edition (DSEE) product, which introduced multi-master replication and 64-bit support, respectively, were very exciting.

But then for some reason, Sun’s directory server engineering team seemed to contract a chronic case of inertia, in which everyone was content to rest on their laurels. It certainly wasn’t because the product had reached perfection, nor from a lack of ideas for improvement. After a while, I became frustrated with the lack of progress, and I wrote a hundred-plus-page document (which became known as the “directory manifesto”) that was full of things that we could do to improve the product. It had plenty of low-hanging fruit that would address pain points that customers were experiencing and lots of bigger ideas to help ensure our continued dominance of the high-end directory server market. But to no avail.

Eventually, I was able to nag the right people long enough to let me start working on a new directory server that was intended to be a DSEE replacement. And thus I became the first developer working on what would become OpenDS. Sun was committed to open sourcing all their software, from Solaris to Java to all of their enterprise software, and before long, we released OpenDS under the same CDDL license that they initially created for OpenSolaris.

At that time, Sun’s Directory Server engineering team was mostly split between Austin, Texas and Grenoble, France. In 2007, someone got the idea that it would be good to have it headquartered all in one place, and Grenoble was chosen as that one place. As a result, the five U.S. employees most closely connected with OpenDS were laid off: director of engineering Steve Shoaff, marketing lead Don Bowen, engineering manager David Ely, open source community manager Trey Drake, and myself as architect.

It didn’t take the five of us long to decide that we wanted to create a new company developing on top of the OpenDS codebase. We were still passionate about the product and excited about the opportunities that it could afford, and we planned to contribute back to the open source community. We even followed through on that with a handful of commits within a couple of weeks of the layoff. But then some nastiness arose between us and Sun’s management that I don’t want to get into here, and it became clear that we were no longer welcome participants.

So by the time we founded UnboundID (on December 17, 2007), we were to be competing against Sun. We’d comply with the terms of the open source license when altering existing code, but newly-created files would be our own private intellectual property, as allowed by the CDDL. We would, of course, also go head-to-head with other directory server vendors, like Oracle (who bought Sun within a few months of our departure), IBM, Microsoft, and CA. And we’d be up against open source offerings like OpenLDAP and the 389 Directory Server. We should’ve had no chance. And yet we were shockingly optimistic. We had a lot of ideas, a lot of drive, and dare I say a pretty good amount of talent.

Upon officially forming the company, David, Trey, and I worked furiously to make improvements to the codebase. We made dramatic improvements in performance, concurrency, and scalability. We added killer features, like support for transactions, filtered logging, change subscriptions, data transformations, data integrity checksums, and some new controls and extended operations. We made the server easier to manage by improving the out-of-the-box configuration, refined the command-line and interactive text-based interfaces, and added a web-based administration console.

We also created a new Java-based API for interacting with LDAP servers, because the existing options sucked. Before we released the UnboundID LDAP SDK for Java, you could basically choose between the horrible, confusing clunkiness of JNDI (where LDAP support is bolted on as an afterthought), or the buggy and no-longer-maintained Netscape Directory API. We wanted to create an API that made it easy to write applications that could take full advantage of any LDAP server, including the enhanced functionality we were building into our own software.

While David, Trey, and I were churning out the code, Steve and Don were working to sell it. And they did. Amazingly, we got our first customer within a matter of months: a large network equipment provider that supplied telephone companies with the equipment used to run their data centers. They loved our software, our enthusiasm, our ability to react quickly, and our willingness to put our source code in escrow so they wouldn’t be screwed if we went out of business. And before long, a number of big telcos were kicking the tires on our stuff and salivating at the idea of a modern, high-powered, feature-rich, and administrator-friendly directory service.

This first customer was a huge win for us. They resold our software and provided first-line support, which helped alleviate any downstream concerns about our viability. They declared our software to be carrier-grade, which served as validation to other potential customers in other industries. And it was also nice to be able to start getting a paycheck.

Plus, we were able to leverage this deal to get good terms on an initial round of funding from an investor. We were able to hire more people (many of whom were former colleagues from Sun who were all too happy to jump ship from their new Oracle overlords), and we started working on new products. David took on the Synchronization Server, and I started on the Directory Proxy Server.

The Synchronization Server provides a way to mirror the contents of two or more data repositories, so that changes made in one system appear in the other systems, usually in a matter of milliseconds. It can do one-way or bidirectional synchronization. It can synchronize all the data or just a configurable subset. And you can connect to a number of different types of repositories, including LDAP directory servers (both UnboundID and non-UnboundID), relational databases, NoSQL databases, and more (plus an API for developing your own support for additional types of data stores). It’s ideal for migrating data from your existing repository into the UnboundID Directory Server, and for keeping both infrastructures in sync for whatever length of time is necessary to complete the migration, or indefinitely if you want to keep both systems up and running.

As its name implies, the Directory Proxy Server is an LDAP proxy server. In the simplest deployments, it allows you to achieve better performance and higher availability through load balancing and advanced health checking techniques. In larger deployments, you can use entry balancing to transparently split data up into multiple sets (much like database sharding) for even greater scalability. It can also transform requests and responses as they pass between clients and backend directory servers, and you can do this on a per-application basis in case some clients have different expectations for how the data should look or how the server should behave.

We continued to grow. We sold more software. We gained more customers. We hired more employees. We wrote more code. But sadly, we also suffered some losses. Trey decided it was time for him to move on, so he left the company. But even more tragically, Don Bowen passed away in late 2009. He’d been diagnosed with brain cancer a mere three days after we founded the company, and somehow he continued to make incredible contributions toward our success for over a year and a half. I met Don in my first job out of college, at Caterpillar, where he introduced me to the world of LDAP. Within a few months, he’d gotten an offer to join the Baltimore-based startup (initially called B2B Communications, but later renamed TidePoint Corporation) and he took me with him. When that went south, we went our separate ways, only to meet up again when we both joined Sun at about the same time. We were friends as well as colleagues, and a tremendous amount of who I am today is because of Don.

And the work goes on. As more customers migrated from existing environments and deployed into new environments, we realized that we needed to provide public interfaces to allow our software to be customized, so we created the Server SDK. Our server products had always been very extensible and componentized, but before the Server SDK, we were the only ones who could take advantage of that. The Server SDK made it possible for customers to write their own extensions to customize the behavior of the server, from intercepting and altering operation requests and responses, to creating new loggers, password validators, extended operations, SASL mechanisms, sync sources and destinations, proxy transformations, and more. The initial intention was to only make the Server SDK available to customers who’d gone through at least some kind of training (it allows you to run custom code inside the server, so there’s a chance that a buggy extension could make the server unusable), and I really wish we’d stuck to that more than we did. But for the most part, it was a hit with customers, and an even bigger hit with the sales engineers helping them evaluate and then migrate to our software.

We also introduced a couple of additional server products: the Analytics Engine and the Data Broker. The Analytics Engine (formerly called the Metrics Engine) provides simple, graphical access to all kinds of historical information about the operation of the server broken down in all kinds of ways (e.g., the number of requests per second of each operation type, and a breakdown of their result codes and processing times), along with metrics from the underlying system like CPU, disk, and network utilization. The Data Broker provides several REST-based interfaces to interact with the environment, including support for OAuth 2 and OpenID Connect (for authentication, authorization, and federation), and SCIM (for data access). As much as I love LDAP and will continue to tout its superiority over HTTP, the kids these days are all about the web APIs, so we must oblige.

But even as we worked on new products, the Directory Server continued to grow and improve. I am particularly passionate about security, so that’s been a big focus of mine over the last several years. We added support for data encryption, several two-factor authentication mechanisms, more password storage schemes and password validators, sensitive attributes, retired passwords, password reset tokens, improved account lockout, signed logs, and more. But we also added a lot of non-security-related features, like JSON support, alarms and gauges, soft deletes, assured replication, and indexing improvements. It’s gotten faster, easier to use and administer, and just plain better.

On the whole, we’ve had an unbelievable run. We did have one down year with less-than-stellar sales, but for all other years, we reached or exceeded our goals. That continued through 2016, which was one of our best years ever (even if you ignore the whole “our company was bought” thing). We certainly weren’t floundering, and we weren’t really even looking to be acquired. We had partnered with Ping Identity on a number of deals in the past, as each company’s software complemented the other’s very well without too much overlap. And then Ping was acquired by Vista Equity Partners, who were looking for other opportunities to get into identity management, and then people started talking and it all sort of became a three-way deal, with the UnboundID acquisition by Ping Identity following Ping’s own acquisition within a couple of weeks.

So what’s next for the bigger, better Ping Identity? I can’t get into any specifics, but we’ve got a lot of great things in the works. Most of the UnboundID staff, and I believe all of the technical staff, are continuing on into Ping. Some people are changing roles (many moving up, others moving laterally), but my job isn’t really changing all that much. I’m still writing code, and hope that continues far into the future. Some of our product names have changed (for example, it’s now the Ping Identity Directory Server rather than the UnboundID Directory Server), and some haven’t (it’s still the UnboundID LDAP SDK for Java), but we’re still working to ensure that they remain the best products out there. So I need to get back to work.

P.S. I know that the only people I mentioned by name in this walk down memory lane are the UnboundID founders. I certainly don’t mean to imply that we’re the only ones responsible for or vital to the company’s success. There are so many other people that made big contributions to the company that I can’t list them all without fear of leaving someone out, without fear of mentioning someone who’d rather be left out, and without fear of making this long post even longer. So let me just say that if you worked for UnboundID in any capacity, you have my sincerest thanks.



UnboundID LDAP SDK for Java 3.2.0

We have just released the 3.2.0 version of the UnboundID LDAP SDK for Java. It is available for download via the LDAP.com website or from GitHub, as well as the Maven Central Repository.

You can get a full list of changes included in this release from the release notes (or the Commercial Edition release notes for changes specific to the Commercial Edition). Some of the most significant changes include:

  • Added a new transform-ldif tool that can be used to apply a number of transformations to data in an LDIF file. This includes the ability to scramble, replace, redact, or exclude a specified set of attributes; to replace existing values for a specified attribute; to use a sequential counter for values of a specified attribute; to add a given set of values to entries matching specified criteria; to exclude entries matching specified criteria; to rename attributes; to replace the base DN for entries in a specified subtree; and to flatten a DIT.

  • Updated all classes that offer a public void close() method that doesn't throw any exceptions other than a possible IOException so that they implement the java.io.Closeable interface. This includes classes like LDAPConnection, LDAPConnectionPool, LDIFReader, LDIFWriter, and all EntrySource implementations. This allows code using these classes to take advantage of the try-with-resources facility introduced in Java SE 7.

  • Added support for parsing entries that contain information about the operations processed in the server for servers that support the syntax described in draft-chu-ldap-logschema-00.

  • Updated the modrate tool to make a number of improvements, including support for a number of controls, the ability to replace multiple values rather than just a single value, or the ability to perform an increment modification rather than a replace modification.

  • Added a new JSONBuffer class that can be used to efficiently construct the string representation of a JSON object, and a JSONObjectReader class that can be used to read JSON objects from an input stream. Added the ability to generate formatted, multi-line string representations of JSON objects with improved human readability.

  • Updated the LDIF reader to make it possible to specify the character set to use when reading data. Updated the LDIF writer to make it possible to automatically include a comment below any base64-encoded values that provides a non-base64-encoded representation (with special characters escaped) of the preceding value.

  • Updated the in-memory directory server to support the LDAP no-operation control as described in draft-zeilenga-ldap-noop-12.

  • Added a new base64 command-line tool that can be used to encode and decode data using the base64 format.

  • Dramatically improved the robustness of the identify-references-to-missing-entries and identify-unique-attribute-conflicts tools.

  • Updated the argument parser to add support for subcommands with their own distinct set of arguments.

  • Added support for timestamp arguments, which can be used to specify timestamps in either the generalized time syntax (including the time zone), or in a number of formats that indicate a time in the local time zone.

  • Updated the command-line tool API to provide the ability to default to interactively prompt for passwords that may be needed but not provided, and to send output to a specified file.

  • Updated the rate adjustor so that generated sample rate files include a number of additional examples for common patterns like square, stairstep, sine, sawtooth, triangle, and hockey stick.


UnboundID LDAP SDK for Java 3.1.1

We have just released the 3.1.1 version of the UnboundID LDAP SDK for Java. It is available for download via the LDAP.com website or from GitHub, as well as the Maven Central Repository.

This is a relatively minor update release, and you can get a full list of changes from the release notes (or the Commercial Edition release notes for changes specific to the Commercial Edition). Some of the most significant changes include:

  • Updated the AddRequest constructor that allows you to create a request from an LDIF entry. It will now accept an LDIF add change record (including the "changeytpe: add" line, and optionally including controls) in addition to an LDIF entry.

  • Added two new LDAP listener request handler implementations that can be used to limit the load that clients can leverage against a listener. One implementation allows you to limit the number of requests that may be processed concurrently, while the other allows you to limit the overall rate (in operations per second) at which requests may be processed.

  • Fixed a bug in which the LDAP connection pool statistics were not always properly updated for a failed attempt to create a new connection for the pool.

  • Added a new --helpSASL argument for LDAP command-line tools that support authentication. This argument obtains a list of the supported SASL mechanisms and the options that are available for each.

  • Updated the command-line argument parser to provide support for using a properties file to supply the default values for arguments not explicitly provided on the command line. Tools that support this feature now include a --generatePropertiesFile argument that can be used to generate a template with the supported properties for that tool.

  • Updated the command-line argument parser to support grouping related sets of arguments together in the usage information.