Here's my 2c. - Bundle-SymbolicName = artifactId is a no-brainer IMHO - groupId should be the organization creating the bundle (so when converting an existing library, the organization that does the converting) - Bundle-Version = version - somebody once proposed dropping the qualifier but then you loose tracability
- The generated POMs are also open for debate. I believe ecipse:to-maven only looks at the manifest and generates dependencies from Require-Bundle, but it ignores Import-Package headers. For versions it creates Maven ranges, but these were unusable without specifying a zillion excludes (at least in 2.0.8). My approach with Tycho is different. I would start with a consistent install (e.g. the full Ganymede release). Tycho's uploader will first perform resolve these bundles against each other using OSGi rules, to decide what the actual dependencies are. The POM dependencies are calculated based on this dependency graph. - For RCP developers, we should also decide what the Eclipse features should look like in the repository. E.g. upload a full feature zip or just a POM that has dependencies on all the member plugins - Regarding all the different bundleizations (is that a word?) that are or will be available for some common libraries: I'm afraid this will only be solved when libraries start producing OSGi artifacts themselves. Perhaps the new spring osgi repository will also help to standardize. Tom On Thu, May 22, 2008 at 6:59 AM, Brett Porter <[EMAIL PROTECTED]> wrote: > > On 22/05/2008, at 2:48 PM, Jason van Zyl wrote: > >> >> On 21-May-08, at 9:23 PM, Barrie Treloar wrote: >> >>> On Thu, May 22, 2008 at 1:06 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote: >>>> >>>> It's not very complicated what we discussed. Essentially it's artifactId >>>> = >>>> symbolic bundle id because you'll never be able to derive the >>>> artifactId/groupId pair from a symbolic bundle id because you don't know >>>> where to split it. So avoid the complication of the mapping. The groupId >>>> would be use for organization in the repository but not important in the >>>> creation of the symbolic bundle id. What this means is that you could >>>> directly retrieve a bundle into a running osgi container without trying >>>> to >>>> synthesize the bundle id which is a good thing. >>> >>> Next question then, >>> >>> when can we seed a maven repository with bundles? >>> >> >> Officially? When we agree. This was a casual discussion we had at >> EclipseCon. Probably wouldn't take long. I imagine most issues could be >> hashed out in a week and then we could try it in a test repository on >> central. > > Sounds like a good approach to me. Perfect timing with the Ganymede release > coming up soon - we could get that release in there, and get it right from > there on. > > So far the proposal seems to be: > - use artifact IDs that most match the final identifiers > - discourage the use of http://repo1.maven.org/eclipse/ and > http://repo1.maven.org/maven2/org/eclipse/ with the old artifact IDs > > The questions I have so far: > > Are the POMs generated by today's eclipse:to-maven goal the right ones to be > using? I'm particularly wondering about the version range issue Vincent > raised. > > What is the policy on bundle-ized versions of existing artifacts? The above > sounds good for org.eclipse itself, but having stuff like this is worrying: > http://repo1.maven.org/eclipse/org/apache/ant/org.apache.ant/1.6.5/ > Worrying because we start duplicating an awful lot of stuff. Is it possible > we could place the OSGi manifest in the repository alongside main ant and > the build process could merge them? And for artifacts that don't have them, > we can generate default OSGi manifest information if incorporated into such > a build? > > Cheers, > Brett > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
