atom feed8 messages in org.apache.ant.devRe: Import Bushel into Ivy
FromSent OnAttachments
Nicolas LalevéeOct 13, 2010 6:38 am 
Antoine Levy-LambertOct 14, 2010 1:18 pm 
Maarten CoeneOct 18, 2010 2:54 pm 
Nicolas LalevéeOct 19, 2010 12:51 am 
Nicolas LalevéeOct 22, 2010 7:04 am 
Stefan BodewigNov 2, 2010 2:41 am 
Nicolas LalevéeNov 2, 2010 4:01 am 
Nicolas LalevéeNov 3, 2010 8:56 am 
Subject:Re: Import Bushel into Ivy
From:Nicolas Lalevée (
Date:Oct 19, 2010 12:51:10 am

Le 18 oct. 2010 à 23:54, Maarten Coene a écrit :

+1 for me. There is a chance I'm going to use OSGi @ work, so this could be a good test case :-)

I've noticed the code is not JDK 1.4 compatible, but I guess it won't be a problem to downgrade it? Or maybe we should drop the JDK 1.4 requirement for Ivy, but I would rather not do that as long as Ant is also 1.4 compatible.

I prefer to keep Ivy JDK 1.4 compatible too, for the same reason. I'll downgrade
the code.


----- Original Message ---- From: Nicolas Lalevée <> To: Ant Developers List <> Sent: Wed, October 13, 2010 3:38:33 PM Subject: Import Bushel into Ivy

Hi all,

I would like to import the code of Bushel [1] into Ivy core.

On the technical part. Bushel implement some special Ivy resolver and version matching which understand the different kind of OSGi dependency, and also understand the repository descriptor OBR (OSGi Bundle Repository). So the import will make those resolver part of Ivy core.

On the legal part. The code has been developed under the ASL2 license and by only three developpers: Alex Radeski, Jérôme Benois and me. I have contacted the two others, they are joining me in this request and are willing to sign any software grant paper necessary. As the code will be imported into Ivy, the "Bushel" name will then disappear. Ivy will then support some OSGi feature.

Deeper in the technical part. As I explained here [2], Ivy cannot fulfill entirely the OSGi resolve specification. But I have managed to make resolve work and I think it can fill some requirement like making some transition from a ivy/maven based resolution mechanism to a pure OSGi based one. Or the reverse. With that respect, we shouldn't lure Ivy users to say that Ivy support OSGi and I suggest that we would flag at first it as "experimental". As users would start to try it, we will see real world case appear, and then we would then advise of its real state. This might sound quite pessimistic, but I find this feature exiting enough to bring it into Ivy core.


[1] [2]