ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: OSGI and IVY
Date Tue, 20 Jul 2010 19:42:51 GMT
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.Castrianni@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message