Torsten Curdt wrote: >>> ...OSGi by default doesn't do any dependency resolution. Either by >>> package, or by 'block'. In which case, if we use Maven for it at >>> build time, we're still stuck with a need for it at deploy time, >>> which seems a little odd... >>> >> >> I don't think we should use Maven for runtime dependency resolution, >> as it's not its role. >> > > ...I think the dependency resolution is definitely an overlap > with maven. The questions is whether there is code or at least > knowledge that makes sense to share. > Would like to avoid too much cross-posting, but here goes :)
Portions of Maven2's code could definitely be used for runtime dependency resolution, if that is required. The code is built around components, of which the artifact management is one that is independant of the rest of the Maven code. This is what is primarily used to build the Ant tasks and exposes all of the dependency features Maven has. It is independant of the metadata (though I haven't done any tests with anything else, there is no tie in the code), so theoretically it could resolve OSGi bundles directly. However if you end up using Maven (or the Ant tasks) as the build system as well, it would work as is using maven-project and the existing POM files from the repository (which should include enough data to construct the information for an OSGi bundle). To draw a parallel to this situation, there is actually a repository-enabled version of the Plexus container that has been used in the past which does runtime resolution of components from the Maven repository using the artifact code - so it is definitely possible. This is basically how Maven 2's plugin architecture works. We have a couple of people looking into writing OSGi build plugins for Maven and with everything going on at the moment in that space, Maven's ability to work with OSGi will definitely be important going forward. Hope this helps. I'll try and follow this thread from the archives of the cocoon list, but feel free to post back to maven-dev again if there are any questions. Cheers, Brett
