I've never had to get this working myself, so my understanding may be a bit off here. It strikes me that, at build time, there are two directions of translation: 1. MANIFEST.MF to ivy.xml: where you want to consume OSGi bundles as if they were an Ivy repo 2. ivy.xml to MANIFEST.MF: when you want to generate a MANIFEST.MF
I don't fully comprehend the use case for #1 myself. But for that you might want to look at a project called bushel: http://code.google.com/p/bushel/ And here's a wiki page: http://code.google.com/p/bushel/wiki/HowToUseIvyWithYourOsgiProject #2 is a more open-ended question. I know it's easy enough to generate a manifest Class-Path entry using the manifestclasspath Ant task and an Ivy-derived classpath. And I'm sure there's a way for manifest-generating tools like bundlor and bnd to take inputs that are derived from Ivy. And it seems like when it comes to generating the Export-Package content, you should be able to stick a placeholder like ${ivy.revision} alongside each package declaration and fill in the current version during the build. Now, when it comes to the Import-Package entry, the question arises as to what version you want to fill in alongside each package, where you do fill in a version. You could get the version from the Ivy dependencies simply to keep your manifest versions from getting out of sync with your ivy.xml, but you'd need some translation mechanism. And even then, isn't one key element of OSGi to allow your runtime dependencies to be more flexible than your build-time dependencies? So you'd be losing something by deciding on one version at build-time. No matter how much you automate and how much you're able to leverage Ivy and a tool like bundlor or bnd, it still seems like you're going to have to do a certain amount of manual composition of a MANIFEST.MF. And you can see how easy it is for Ivy versioning and bundle versioning to get out of sync with each other. I don't know if this has been fixed with Ivy 2.2.0, but if you look at the MANIFEST.MF for the 2.1.0 Ivy JAR itself, you'll find references to Ivy 2.0.0 under Export-Package: Export-Package: org.apache.ivy;version="2.0.0" Maybe the key question is, what does your team hope to accomplish with OSGi? The answer could determine how much of a mismatch there is between the two paradigms, OSGi/runtime and Ivy/build-time. Anyway, you can see I'm half answering you and half asking this question in my own right. I have a need to obtain a Java application's dependencies at runtime so that they don't have to be distributed with the application, otherwise every time the dependencies change, you need a new application. I'm not quite sure what the "right" solution is to this problem. On Tue, Jul 20, 2010 at 10:53 AM, Shawn Castrianni < shawn.castria...@halliburton.com> wrote: > Has anybody researched the relationship between OSGI and IVY? I have a > large build system running on IVY and is working great. However, > development wants to move towards an OSGI runtime framework which impacts > how the modules are built. I am trying to figure out how I can merge in > OSGI bundle creation with my IVY based build system. > > I am finding that the dependency mechanism and publish mechanism in OSGI is > fighting with the same concepts in IVY. Therefore, I am not making any > progress on this OSGI project. > > Has anybody spent any time researching OSGI and have any thoughts on it in > relation to IVY? > > --- > Shawn Castrianni > > ---------------------------------------------------------------------- > This e-mail, including any attached files, may contain confidential and > privileged information for the sole use of the intended recipient. Any > review, use, distribution, or disclosure by others is strictly prohibited. > If you are not the intended recipient (or authorized to receive information > for the intended recipient), please contact the sender by reply e-mail and > delete all copies of this message. >
