Impossible to register own server type

[domgold]

I order to allow a more flexible configuration of the unboundid server, I have created a new server artifact and added this artifact as dependency to my plugin.

The only way to get it discovered by the ldap-maven-plugin, is to have the same groupId (com.btmatthews.maven.plugins.ldap) as the other server artifacts. I think this has something to do with

DEFAULT_GROUP_ID = "com.btmatthews.maven.plugins.ldap";

in IncludeServerDependenciesComponentConfigurator.java

Is there a possible workaround?

If not, would it be possible to configure the DEFAULT_GROUP_ID in a futur version of the plugin?

[bmatthews68]

At the moment there is no way around that limitation. Another limitation you will encounter is that the version number used to resolve the dependency is the same as for the plugin.

I'm trying to get the plugin working with Maven 3.1 and 3.2. I'll see if I can make it more flexible at the same time. I've been trying to get time to do that over the last couple of weeks but have been very busy at work.

Also I am curious about what customisations you require for the UnboundID server. Are there some features you think are missing that I should incorporate? I am happy to accept a pull request.

On 3 September 2014 10:27, domgold notifications@github.com wrote:

I order to allow a more flexible configuration of the unboundid server, I have created a new server artifact and added this artifact as dependency to my plugin.

The only way to get it discovered by the ldap-maven-plugin, is to have the same groupId (com.btmatthews.maven.plugins.ldap) as the other server artifacts. I think this has something to do with

DEFAULT_GROUP_ID = "com.btmatthews.maven.plugins.ldap";

in IncludeServerDependenciesComponentConfigurator.java

Is there a possible workaround?

If not, would it be possible to configure the DEFAULT_GROUP_ID in a futur version of the plugin?

— Reply to this email directly or view it on GitHub https://github.com/bmatthews68/ldap-maven-plugin/issues/17.

[domgold]

I customized unboundid server to be able to initialize the schema using an ldif file. And to be able to include multiple ldif files. My current solution isn't very clean, but it works for me (with groupId set to com.btmatthews.maven.plugins.ldap and version set to plugin version). I will post my solution here if I find some time.

[bmatthews68]

One of the features included in the next release will be the ability to seed the directory with multiple LDIF and/or DSML files similar to the way the load goal currently works.

But I don't want to release that until it all works with Maven 3.1 & 3.2.

On 3 September 2014 10:59, domgold notifications@github.com wrote:

I customized unboundid server to be able to change the initialize the schema using an ldif file. And to be able to include multiple ldif files. My current solution isn't very clean, but it works for me (with groupId set to com.btmatthews.maven.plugins.ldap and version set to plugin version). I will post my solution here if I find some time.

— Reply to this email directly or view it on GitHub https://github.com/bmatthews68/ldap-maven-plugin/issues/17#issuecomment-54275216 .

[domgold]

I found a possible solution to my issue. But before making a pull request, I wanted to know your view.

I added my custom server dependency as plugin dependency. Currently this does NOT work because an exception is thrown in IncludeServerDependenciesComponentConfigurator, in getServerDependencies() if the server dependency can't be found by the component configurator. If you only log a warning here, we can :

• still auto-discover standard server dependencies using the component configurator.
• use custom server dependencies by adding them to the plugin's classpath manually.

Additionnally, in order to avoid confusion and have a clear error message in case no matching dependency is found, you could add a null check for factory in AbstractRunMojo#execute() and throw a MojoFailureException when it's null, saying that we should add the missing dependency.

Another alernative would be to check directly in the component configurator if we already have a matching server factory on the classpath, and only try to locate additional dependencies if we don't have a match.