On Tuesday 30 May 2006 23:16, Jeff McAffer wrote: > Niclas Hedhman <[EMAIL PROTECTED]> wrote on 05/30/2006 03:00:53 AM:
> This looks like an incompatibility between Maven and OSGi. As I > understand your point, the maven-osgi plugin does some sort of > transformation to make the version number acceptable at runtime. The OSGi > spec does not allow '-' separators in the version number and Eclipse tools > the OSGi spec. So this one may be harder to work around. Yes, I added that the XX-Package set is scanned for version clauses and exchanges the "-" with ".", as OSGi allows for a "qualifier" after the micro part. IIRC, the spec doesn't discuss file names with or without version in them, in which case it is not about the OSGi spec, but about Eclipse tooling... > > * Equinox makes concessions to support Maven's style. > > As pointed out above, we can certainly look at supporting '-' in the JAR > file name. The only place we care is in some of the boot code that needs > to search for bundles. We try to avoid doing this at all costs and are > generally successful but given that our version numbers change very > frequently (every build) some level of searching at boot time seems > unavoidable. Yep, I happened to have investigated the scanning for the use in osgi.bundles property, as it took me quite a while to figure out a problem a few months ago with the dash character... ;o) > > * Maven makes concessions to support Equinox's style. > > I would rephrase as enhancing Maven to better support OSGi. Certainly if > Maven allowed _ as the name/version separator in the JAR name that would > be ideal but the other issues seem more fundamental/important. Maven is faced with a different angle of the same problem. Given group+artifact+version+qualifier, it must download the artifact from a known location, which is not "list files" capable. There is a slight possibility to have the "Project Object Model" (pom) file containing the separator, and let the pom file have the hard coded dash as a separator, whilst the other artifact types of the same group+artifact will follow the declared separator. I think such change is very core in Maven, and would probably be hard to get them to agree on, even if we do all the work. > > * We make a program that takes the published Maven artifacts, rename > > and republish to an Eclipse Update site, and possibly an OBR as well. > This is interesting. Are you saying that when an artifact is taken out of > the repo it should be renamed for use at runtime? This feels like a > potential disconnect. Well, the Maven problem is not so much about "local development", as one can define a <finalname> for the Jar file in any format one wishes. The problem is that during the "release process" where the artifacts gets uploaded to the repository, it will use the well-formed artifact name, and not the <finalname> declaration. Now, it seems that there are a couple of "provising methods" to be handled; * Local development * Media, CD, zips and so forth * OBR * Eclipse Update If we had a "public OBR" function, which is given a released group+artifact+version, it could pick it up from the Maven central repository, mangle it to suit OBR and then perform the upload and whatever else required. Same principle for any other 'provisioning destination'. > To me the essential point is that a bundle be standalone so that it can be > used, unmodified, in many contexts. This means that it be self-describing > and that the bundle JAR be uniquely named. As I understand the current > situation, Maven avoids collisons by having a groupID/artifactID structure > in the repo. For example, you could take the > org.eclipse.core.runtime_3.2.0.jar bundle and make "org.eclipse" the group > id and "core.runtime" the artifact id (with "3.2.0" the version and "jar" > the type). Is that correct? Essentially, yes. The dots in the groupId are exchanged for file separator, to minimize single directory entries on public server (which has been huge problem before this was introduced), whereas the artifactId is not. > This works well as long as you have a repo (local or remote) structure > that includes groupids. When shipping a product (either on the media or > on the provisioning server) you may not have this level of control and > maintaining this structure complicates management agents. The crux of the > problem is that the bundle jar itself is not standalone since its name is > not unique. The JAR is only unique in a context (i.e., group). I understand your point, but I have no particular reason to neither endorse it nor condemn it. There are arguments in both directions. Eclipse's solution is only one of many possible paths, and I hope you agree that Eclipse is a bit of overkill to be required for OSGi development in general. I have made a Maven compatible product in the past, named Transit, which allowed for protocol based retrieval and local caching of artifacts, with a format of; artifact:jar:[group]/[artifact]#[version] Transit allows for many "repository hosts" and each such host has a "Layout", which could be maven1, maven2 or eclipse. And to obtain the content one just do the; new URL( "artifact:jar:log4j/log4j#1.2.8" ).openStream(); In that perspective, "files" didn't exist from the developers perspective, only the artifacts, and whether the structure is flat or not became totally irrelevant. So, therefor, I am somewhat less inclined to "play along" with the statement that "flat" == "easiest". "flat" just brings a different set of issues, and then a subjective priority has to take place of which issues are better than others. I still don't have a prioritized list, but feels bound by the limitations of the tooling available, and am now faced with "one or the other", which I feel to be a total loss for many... > Side comment: publishing as an update site is interesting but we are > certainly not pushing for that (at this time). Ok. > I would rather see update > get more flexible to it can better understand other repo formats than try > to get everyone to adopt our structure. Agree. Cheers Niclas
