Hi, I noticed you work on support for so-called transitive dependencies in Maven 2.
In the absence of support for it in the current Maven release we developed a solution for this specific to the needs in our projects. Now, I would like to compare your concepts with ours. But it seems to me you haven't yet published a coherent explanation of the mechanisms you invented to make transitive dependencies work. I try to outline our concepts in a nutshell. Maybe you can tell me how these relate to yours: We distinguish projects into components and assemblies. A Maven project.xml either defines an assembly or a component. A component has code and only defines its direct, i. e. non-transitive dependencies in its project.xml. An assembly, on the other hand, doesn't have code but only configuration. And, above all, it defines all the dependencies to the assembled components including the transitive ones in its own project.xml. Transitive dependencies can be distinguished from non-transitive ones in the assembly's project.xml by a dedicated dependency property. Duplicate dependencies are eliminated and version conflicts are resolved in the assembly's project.xml. We deal with almost 100 components, i. e. Maven projects which are being further developed by us plus a large number of third party jars. On top of this we currently manage some 20 assemblies. New versions of these components practically pop up every day. All in all, this means that we have a very dynamic configuration management environment. In order to a) create assemblies efficiently and reliably, and b) keep up with the advent of new versions of dependencies in the project.xml files of dependees we developed a gui tool that uses a configurable strategy to create and update project.xml files of assemblies and components. The tool... - has an integrated repositories browser, - allows to add and to remove non-transitive dependencies to/from a project - allows to browse transitive and non-transitive dependencies and dependees recursively to an arbitrary depth - allows to analyse version conflicts in the dependencies - computes the recursive hull of indirect dependencies if the project is an assembly - automatically resolves the conflicts by selecting the appropriate version per artifact according to a selectable default strategy and user-defined exception rules - offers two default strategies: one is to select the latest release of an artifact and the other is to select the SNAPSHOT if no other rule fires The latest release strategy can distinguish between repositories which are to be scanned for the latest release available and those which are not. If the latest release is desired for an artifact that resides in a repository which must not be scanned, the search for the latest release is confined to what is reachable in the dependency graph that roots in the project currently being maintained with the tool. The latter is useful for repositories of third party artifacts which are not under full control of the software project that uses it. Here, one doesn't want to fish the latest stuff only because it exists (put there by some foreigner) but only when at least one of one's own components' really states a need for it. User-definable exception rules allow to enforce a specific version for a dependency or to deprecate, i. e. exclude specific dependencies from the list of candidate versions. In the extreme, the user could thus nail down the version for each artifact if the default rules don't yield what he desires). The default strategy and the exception rules are saved as properties in the respective project.xml. This way they are available in the next tool session again. --End of the outline of our concepts I suspect that you have arrived at a similar but surely not identical solution. Especially, I wonder how you give full control to the assembler on which versions to use in conflict situations, because I don't think you distinguish between dedicated assembly projects and component projects, don't you? The other thing that worries me is: do you compute transitive dependencies each time again when you touch the project.xml with a Maven command? I'm not asking this because I'm afraid of performance, although that could be an issue, too. But I fear the indeterminism. Regards, Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
