
Originally Posted by
marshallmccain
First off, great work on the new dm Server. You guys are turning stuff around at an incredible pace!
Thanks! It's great to hear that you like it.
I have read the
dm Server User Guide chapter on configuring the server to scan my ivy-cache for looking up bundles. However, the guide is ambiguous in regards to the setup for searching for libraries in the ivy-cache. I've tried several configurations and cannot seem to get it to work.
My ivy-cache is laid out in the following manner:
- org (ex: org.springframework)
- name (ex: org.springframework.spring-library)
- version (ex: 3.0.0.M3)
- library file (ex: org.springframework.spring-library-3.0.0.M3.libd)
I think it would be helpful to list examples on how the wildcards resolve (i.e., {org}, {name}, {version}, {bundle}, {library}, etc.).
The repository implementation uses Ant-style path matching under the covers, with each of the {foo} wildcards simply being an alias for a * in an Ant-style path. In your case, the configuration should be {org}/{name}/{version}/{library}.libd. This'll map down to */*/*/*.libd. You can use the Ant-style format in the configuration if you'd prefer. The {foo} wildcard format is simply there to aid readability.
Also, if a path in the configuration is relative, it's taken as being relative to the server's home. You can also use an absolute path in the configuration.
Let me know how you get on, please. Once we've got you up and running, and like to know what information was missing / unclear in the user guide so that we can improve it.
Also, I'm curious why the internal dm Server repository search paths for bundles only use {bundle} and not {bundle}.jar?
The reason for this is that the repository supports "exploded" bundles, i.e. a bundle that's in the form of a nested directory structure. In this case the name of the bundle's directory is unlikely to end with .jar so {bundle} is used so that all files (jars and directories) are found by the repository.
Andy Wilkinson
SpringSource