Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pde-build-dev] Eclipse bundles on the Maven repository



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

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

I would not put the rt.jar and its siblings in the repo and it is not necessary to specify full paths.  Normally it will use what is on your path, but the eclipse-compiler plugin would have special needs.  There are several ways that this can be done and mostly you would want to use properties for this.  You can have something like <bootclassapath>${ eclipse.compiler.bootclassapth}</bootclasspath> and have the property resolved within the plugin (bad idea IMHO), within the pom, within a profile or IIRC there is a way to specify this as a default for the whole maven installation.  As a last resort the property can be specified on the command line.  I would favor the use of profiles as they work pretty similar to how eclipse now has Execution Environments.  The difference being you can stack up and activate multiple profiles while you can only have 1 Execution Environment.

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

Adding the manifest as an attachment requires very little work to achieve.  I'll look into working this out today/tomorrow.  However, there isn't currently an index of everything in a repo.  This is why I was thinking we would need the dependency-pom mechanism I was previously talking about as this would map to the current use of an eclipse target to compile against.  The maven-eclipsecompiler-plugin would be configured with 0 or more dependency poms.  The code in the plugin (or if we can push it back, maven itself) would load and resolve a dependency pom down to its component dependencies.  From each dependency it will load the manifest.mf containing imports/exports.  Paths to the actual jars files are retrieved from the Repository instance.  At this point, I'm hoping eclipse would have the same information from the repo that it would have if it used a target folder.

Use of the repo is the end game, but I'm hoping we can move forward with using a target folder to work out other kinks, seen and unseen, while the end game is worked on.

-Andrew



Back to the top