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

[Andrew Niefer <aniefer@xxxxxxxxxx>]

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

Fundamentally, yes it is setting the
bootclasspath.  However, it would be nice to abstract it one layer
so the bundle did not need to specify paths to jars.  I don't know
how maven normally handles this, do you put the jars in your local repo
and just express a dependency on them?  It would be nice to just say
"I need J2SE-1.3" have maven know where to find it.

> 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.

Yes.  Because we can't list the
contents of a repository, we need a way to answer the question "Does
the repo contain some bundle that exports package foo?".  Once
we know that a bundle exists, then we can find it in the repo and download
the manifest.  Having the manifest available separate from the jar
would be good since it allows us to reason about dependency resolution
without having to download the jars right away.

-Andrew

"Wendell Beckwith" <wbeckwith@xxxxxxxxx>
Sent by: pde-build-dev-bounces@xxxxxxxxxxx

06/13/2006 12:05 PM

Please respond to
"Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx>

To	"Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx>
cc
Subject	Re: [pde-build-dev] Eclipse bundles on the Maven repository

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 

_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev