Re: [pde-build-dev] Eclipse bundles on the Maven repository

["Wendell Beckwith" <wbeckwith@xxxxxxxxx>]

On 6/13/06, Andrew Niefer <aniefer@xxxxxxxxxx> wrote:

Another thing to remember with the compiler plugin is the bootclasspath.  PDE Build considers the manifest's Bundle-RequiredExecutionEnvironment (along with a build.properties jre.compilation.environment) to choose on a per plugin basis which jre to compile against.

Are you saying that we would just need to add a <bootclasspath/> element or do you see something more involved required?

Specifying the eclipse target to resolve against is a good first step.  The second step as you point out is using the mapping to find unsatified requirements in the maven repo.  Though satisfying an import package requirement will requirement more meta-data about the repository, something like an OBR.

This is the info I see for commons logging in the osgi alliance's bundle repo:

bundle; manifestversion=2; presentationname=Jakarta Commons Logging; symbolicname=org.apache.jakarta_commons_logging; version=1.0.3.v200604131758
Export Package .; version=0.0.0
Export Package org.apache.commons.logging; version=0.0.0
Export Package org.apache.commons.logging.impl; version=0.0.0
Export Package .; version=0.0.0
Export Package org.apache.commons.logging; version=0.0.0
Export Package org.apache.commons.logging.impl; version=0.0.0

Is this the type of meta data you meant would be needed?  Now that I think about it, nothing prevents us from adding the Manifest.mf itself as an attachment to the jar artifact being installed/deployed to a maven repo.  Thus the compiler wouldn't even have to open the jars to get at the manifest data.

As far as groups go, as Tom pointed out in another email, I think this is maven's notion of POM's with type pom.  I'm still a little fuzzy on this and its unclear to me whether or not features map directly to this kind of aggregation pom.

I forgot about the pom type mapping (sometimes I can't see the forest for the trees) but on the drive in today I'm not convinced it solves everything without additional work.  The main hold up is that I don't believe you can specify other pom mappings in the dependency section of one pom and have the dependencies transitively resolved.  Take this an example of an org.eclipse.platform-3.2.pom:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.eclipse.platform</groupId>
  <artifactId>org.eclipse.platform</artifactId>
  <name>Eclipse Platform</name>
  <version>3.2.0</version>
  <inceptionYear>2006</inceptionYear>
  <dependencies>
    <dependency>
      <groupId>org.eclipse.core.runtime</groupId>
      <artifactId>org.eclipse.core.runtime</artifactId>
      <version>3.2.0</version>
    </dependency>
    ...
    <dependency>
      <groupId>org.eclipse.core.resources</groupId>
      <artifactId>org.eclipse.core.resources</artifactId>
      <version>3.2.1</version>
    </dependency>
    <!--
    Adding the following dependency may screw up normal maven.
    Perhaps we should have a different type with our own registered artifact
    handler.
    -->
    <dependency>
      <groupId>org.eclipse.equinox</groupId>
      <artifactId>org.eclipse.equinox</artifactId>
      <version>1.2.3</version>
      <type>dependency-pom</type>
    </dependency>
  </dependencies>
</project>

The last dependency should be resolved to another pom which is recursively resolved to all dependencies.  When we get the recursive resolution done then this will work like a charm.

Artifact mappings is another good topic to work out.  Fragments and Plugins map fairly directly to jars in the maven repo.  We could add attachments to the installed/deployed artifacts that carry meta data of use in the dependency resolution stage in necessary.  Features seem to map to these dependency poms but they also have an attachment being the feature jar itself.  On first thought, update sites would plug into maven's site generation lifecycle to be created and deployed with the site:site and site:deploy goals respectively.

-Andrew