Brett Porter <[EMAIL PROTECTED]> wrote on 08/27/2005 10:00:30 PM: > On 8/28/05, Jeff McAffer <[EMAIL PROTECTED]> wrote: > > From what I have seen of the the M2 OSGi > > plugin, it looks like much of what would normally go in the manifest.mf of > > a bundle is to be put in a maven POM file and then the build generates the > > manifest? > Correct.
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. 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. 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? > > How are the dependencies managed and compile-time > > classpaths computed? > > Dependencies and their version(s) are listed in the POM. The Maven > repository is used to lookup dependencies of those dependencies and > build a graph, determining the optimal version to use. Each dependency > can be declared as a compile, runtime or test scope, which affects how > the classpaths are created for each of those phases of the build and > the final packaging. 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. 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. > > For example, the org.eclipse.pde.ui bundle directly > > or indirectly requires about 40 bundles on its compile-time classpath. > > What is the M2 structure for this? > > I would assume most of those are not direct, but derived from its > direct dependencies, which Maven can determine as long as the metadata > exists for all those dependencies also. 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. > > We could talk about this here or at [EMAIL PROTECTED] > > Ok, I've subscribed. I'm happy to discuss it in either place too. Great. I posted a starter topic there for Eclipse/PDE specific discussion. Thanks Jeff
