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