Hi Sebastian,

> I've come across a lot of blocking issues when compiling even the
> simplest HelloWorld Eclipse plugin with Ivy [trunk]. See: IVY-1329,
> IVY-1330. More bug fixes/reports to come in the next few days.

thanks for the patches. I have just applied them.

> So I'm wondering if there is anyone out there who uses this feature at all.

As stated in the doc, it is quite experimental, because not that well tested. 
And having the OSGi model fit into Ivy's one is not trivial.

> It's mostly working now after tweaking the OSGI code in various
> places. But I'm stuck on something that I'm not sure how to attack.
> 
> After generating the OBR XML there are two bundles which look
> something like the following:
> 
> repo-eclipse.xml (generated using a fixed version of the
> eclipse-plugin example ivy project):
> ...
> <resource symbolicname="org.eclipse.equinox.common" version="3.6.0.v20110523"
>               
> uri="file:/home/skrueger/dev/eclipse-RCP-3.7.1/plugins/org.eclipse.equinox.common_3.6.0.v20110523.jar">
> ...
>               <require name="package"
>                       
> filter="(&amp;(version&gt;=1.0.0)(!(version&gt;=2.0.0))(package=org.eclipse.equinox.log))"
> />
> ...
> <resource symbolicname="org.eclipse.osgi" version="3.7.0.v20110613"
>               
> uri="file:/home/skrueger/dev/eclipse-RCP-3.7.1/plugins/org.eclipse.osgi_3.7.0.v20110613.jar">
>               <capability name="package">
>                       <p n="package" v="org.eclipse.equinox.log" />
>                       <p n="version" v="1.0.0" />
>               </capability>
> ...
> 
> The issue here is that Ivy will throw the following error:
> ---
> eclipse: unacceptable revision => was=3.7.0.v20110613 required=[1.0.0,2.0.0)
> ---
> org.eclipse.equinox.common requires org.eclipse.equinox.log version
> [1.0.0,2.0.0) but seems to only find version 3.7.0.v20110613.
> 
> The bug appears to be that when resolving package capabilities in the
> OBR XML the require is compared to the resource/@version and not the
> resource/capability[name=package]/p[n=version]/@v.

There is certainly a mixup here between the package requirement and the bundle 
version. This probably comes from the way the mapping of a package requirement 
on a bundle implementation is done.

See RepoDescriptorBasedResolver#findIvyFileRef. Here Ivy is tricked: asked for 
"org.eclipse.equinox.log [1.0.0,2.0.0) osgi:type=package", this obr resolver 
returns "org.eclipse.equinox.log 3.7.0.v20110613 osgi:type=bundle".
Then later Ivy gets confused, we should find a proper way to make Ivy 
understand the difference.

> The issue goes away if I manually edit the generated OBR XML and
> change the version to 3.7 for the package capability. However, it
> would be better if the resolver code would actually resolve this one
> correctly.

I have just checked in a possible fix. Force Ivy to not check the version is 
the module is not a "bundle".

Hope it helps,
Nicolas



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to