On 8/28/05, Jeff McAffer <[EMAIL PROTECTED]> wrote: > In general I think this is going to be a challenge. For example, in OSGi > Require-Bundle (and other places) you can specify version ranges and other > directives/attributes.
Likewise in Maven 2. As luck would have it, it seems we both used set notation so it is going to be very familiar and easy to map. It'd be great to get a look at the details of how this is handled (how ordering of versions is defined, how conflicts are managed) so that we can ensure they are as close as possible, or at least that there are ways to do everything in both. > OSGi developers understand these and likely want > to express their dependencies in those terms. Seems that with the Maven > approach developers have to craft POM files using a syntax that is > unfamiliar and may not match the capabilities of the underlying (to be > generated) metadata. Also, as the world bundlizes, there will be many > bundles with manifest.mf data. Who is going to write the POM files? Is > there a way of generating POM data from OSGi manifest.mf data. It would certainly be possible as a starting point. That should be enough to deploy to the repository and have the dependency mechanism work. For those building with Maven, they will maintain the POM and generate the OSGi data. It should be understood that Maven is no longer a Java-centric tool and aims to do more than just build jars and manage dependencies. > FWIW, the Eclipse approach is to supplement the manifest.mf with > build-specific metadata (build.properties) that maps development time > structures onto runtime structures. PDE Build (our builder) then uses > this and generates build scripts (Ant in our case) and then run them to do > a build. Perhaps one approach is to generate POM data instead? That sounds like the right approach. From flicking through build.properties that I've seen so far, there are compartive fields in the POM for these. > I'll have to read up on the scope stuff. More generally though I am > intrigued by Maven resolving the dependencies. How does it know about the > OSGi dependency model? For example, Import-Package and Fragments. The > resolution of those dependencies is really quite complex. It doesn't right now. I don't know how Import-Package and Fragment work exactly (some digging around only led me to basic tutorials, I probably need to have a look at the specification). I'm still learning OSGi. If these dependencies need to be resolved at build time, I have some ideas about how it could be handled, but I'd need to learn more before I think more about it, but... > Again FWIW, PDE uses the actual OSGi resolver to determine the > compile-time classpath based on the available bundles. In this way the > compile time setup looks exactly like the runtime setup. We can plug in other resolvers, so this might be an option too. > Question: How well do Maven's dependency management algorithms scale? For > example, what are typical repository sizes and dependency depths or graph > sizes? This has bearing here as some people build systems of several > thousand bundles. I don't see any limitations on the scale as long as the data and versioning is set up correctly. > Great. I posted a starter topic there for Eclipse/PDE specific > discussion. I'll introduce myself. Thanks for the information. Cheers, Brett
