Hi Alex, Looks like interesting stuff, and addresses some of the problems I had noticed but didn't have the knowledge to resolve (e.g. bootstrap v. global registries).
I do have a few comments to make from my biased "ApacheDS used to house third party custom partition" point-of-view: 1. I'd be much happier if the ".schema file => schema partition" tool were instead (or also) available as an optional start-up mechanism activatable by uncommenting support in server.xml. In the use-cases dear to my heart users are able to easily register dynamic custom partitions along with the .schema files they depend on by simply placing files in various filesystem directories (ala appservers) rather then having to run separate utilities. Given this point I'd most probably do away with a maven plugin for the ".schema => schema partition" bit and replace it with code to determine whether the .schema partition needed to be populated with bootstrap information on its first run after deployment (from .schema files included in a release .jar). For dynamic updates/additions of .schema files the relevant filesystem directories could be polled for changes periodically (again ala appservers). 2. Being able to change schema information is a very power-user feature, but I'd imagine that a much more common usage is simply wanting to add extra read-only schema information (matching various RFCs and/or basically static schemas defined by third party vendors) after deployment. In my usecases storing the thirdparty (i.e. non-core) schema information persistently is actually a minus rather then a plus; I'd prefer my users could deploy another custom partition with updated schema information and restart AD without having to worry about clashes with existing information. Is it theoretically possible to indentify various schema subtrees as "read-only" so that they can't be changed and aren't persisted, but are instead transiently populated from .schema files at start-up? 3. Whether modifying schema information via piece-meal updates or whole .schema file imports, we face questions re versioning / draining of pending requests referring to old version of the schema etc. Is the race condition between schema changes and other operations referring to the schema some that needs to be considered now, say by synchronizing access to the schema partition. I know my focus is out of whack with AD's primary objectives, in that I don't use it as a persistent store at all, but even so I see populating at start-up rather then maven plugin + import utility as a universal plus in terms of flexibility / amount of code required. Thanks
