Niclas Hedhman <[EMAIL PROTECTED]> wrote on 05/30/2006 03:00:53 AM: > There are a few restrictions imposed by Maven. > * ArtifactID WILL become part of the filename together with Versionand Type. > <finalname> is NOT respected for repository uploads. This would require the > FQDN style to use the FQDN in both group and artifact, generally > discouraged by the Maven peeps, but totally doable.
Maven question: Why is the group id influenced by the name chosen for the artifact? That is, why would FQDN need to be used for both? > * Versions are appended to filename (as well as being part of the directory > structure) with a DASH. Underscore is not possible. Dash is technically feasible for us to allow in Eclipse. It would be interesting to see if Maven could allow underscore. > * Versions during development contains -SNAPSHOT, which Equinox does not like > anywhere, and OSGi doesn't like in its own versioning (handled by plugin). 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. > So, from my PoV it seems that Eclipse vs Maven is fairly incompatible on this > point, and I can only see three ways out; > > * 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. > * 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. > * 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. We've been working really hard to make seamless the path between development time and runtime. That is, you run the bundles you develop against without doing a deployment step or some such. 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? 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). Side comment: publishing as an update site is interesting but we are certainly not pushing for that (at this time). 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. Note also that to date, the vast majority of our installations come as zips or product installs and do not involve update sites (at least not in the initial provisioning). Jeff
