Hi, I migrate to the new Bindex version (from the SVN). The issue comes from a change in the id format. In the old version the ID was an int, in the newest version it is a String (symbolicName/version). The new version does not compute the id, as it reuses the computed id (computed from bindex).
Thanks for the feedback. Clement > -----Message d'origine----- > De : Bart Elen [mailto:[EMAIL PROTECTED] > Envoyé : mardi 4 décembre 2007 11:13 > À : [email protected] > Cc : [EMAIL PROTECTED] > Objet : Re: OBR resource/@id attribute > > Hello Guillaume, > > You are right, the newest version of the id is changed in the newest > version of the Bindex tool. > > Here, this doesn't cause problems for the Bundlerepository bundle, but > it does for the > maven-obr-plugin bundle! > > The line > > int id = > Integer.parseInt(node.getAttributes().getNamedItem("id").getNodeValue() > ); > > of the method > > private boolean resource(Node node) > > of the class > > ObrUpdate > > In > > http://svn.apache.org/viewvc/felix/trunk/maven-obr- > plugin/src/main/java/org/apache/felix/sandbox/obr/plugin/ObrUpdate.java > ?view=markup&pathrev=590935 > > causes the exception. > > > I think this bundle is maintained by Clement Escoffier. I have added > him in CC to inform him about > this bug. > > > > Greetings, > > Bart > > > > > > > > > Guillaume Nodet wrote: > > Well, I just use the svn trunk version of this tool. > > I'm not sure if this has changed at some point, but the ResourceImpl > class > > clearly does not use an integer for the ID. > > Look at > > > http://www2.osgi.org/svn/public/trunk/org.osgi.impl.bundle.bindex/src/o > rg/osgi/impl/bundle/obr/resource/ResourceImpl.javaand > > search for the getId() method. It is implemented that way: > > > > public synchronized String getId() { > > if ( id == null ) > > id = symbolicName + "/" + version; > > return id; > > } > > > > So my repository.xml looks like: > > > > <resource id='org.springframework.bundle.spring.core/2.5.0' > > presentationname='spring-core' symbolicname=' > > org.springframework.bundle.spring.core' ... > > > > > > Which then throws the mentioned exception. > > > > On Dec 3, 2007 5:27 PM, Bart Elen <[EMAIL PROTECTED]> wrote: > > > >> Hello Guillaume, > >> > >> could you give a little more information about how we can reproduce > this > >> error? > >> > >> When I use the bindex tool on the org.ops4j.pax.web.extender bundle, > I get > >> an int as resource ID in > >> the repository xml-file: > >> > >> <resource id='4' presentationname='OPS4J Pax Web Extender Service' > >> symbolicname='org.ops4j.pax.web.extender' uri='pax-web-extender- > 0.1.0.jar' > >> version='0.1.0'> > >> > >> > >> Could you copy this part of your repository xml-file? > >> Did you adapt the repository xml-file manually? > >> > >> > >> Greetings, > >> > >> Bart > >> > >> Guillaume Nodet wrote: > >>> It seems there is an incompatibility between felix obr > implementation > >> and > >>> the indexer tool provided by the OSGi Alliance (see > >>> > >> http://www.osgi.org/blog/2007/07/osgi-bundle-repository-indexer- > open.html > >> ). > >>> The reason is that I have the following exception: > >>> > >>> [WARNING] Exception while updating OBR: For input string: " > >>> org.ops4j.pax.web.extender/0.1.0" > >>> java.lang.NumberFormatException: For input string: " > >>> org.ops4j.pax.web.extender/0.1.0" > >>> at java.lang.NumberFormatException.forInputString( > >>> NumberFormatException.java:48) > >>> at java.lang.Integer.parseInt(Integer.java:447) > >>> at java.lang.Integer.parseInt(Integer.java:497) > >>> at org.apache.felix.sandbox.obr.plugin.ObrUpdate.resource( > >>> ObrUpdate.java:492) > >>> at > org.apache.felix.sandbox.obr.plugin.ObrUpdate.walkOnTree( > >>> ObrUpdate.java:443) > >>> at > org.apache.felix.sandbox.obr.plugin.ObrUpdate.walkOnTree( > >>> ObrUpdate.java:455) > >>> at > >> org.apache.felix.sandbox.obr.plugin.ObrUpdate.updateRepository( > >>> ObrUpdate.java:217) > >>> at org.apache.felix.bundleplugin.OBRInstall.execute( > >> OBRInstall.java > >>> :98) > >>> at > org.apache.maven.plugin.DefaultPluginManager.executeMojo( > >>> DefaultPluginManager.java:443) > >>> at > >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals( > >>> DefaultLifecycleExecutor.java:539) > >>> at > >>> > >> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLife > cycle > >>> (DefaultLifecycleExecutor.java:480) > >>> at > >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal( > >>> DefaultLifecycleExecutor.java:459) > >>> at > >>> > >> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandl > eFailures > >>> (DefaultLifecycleExecutor.java:311) > >>> at > >>> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments > ( > >>> DefaultLifecycleExecutor.java:278) > >>> at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute( > >>> DefaultLifecycleExecutor.java:143) > >>> at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java > >> :334) > >>> at > org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > >>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > >>> at sun.reflect.NativeMethodAccessorImpl.invoke( > >>> NativeMethodAccessorImpl.java:39) > >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke( > >>> DelegatingMethodAccessorImpl.java:25) > >>> at java.lang.reflect.Method.invoke(Method.java:585) > >>> at org.codehaus.classworlds.Launcher.launchEnhanced( > >> Launcher.java > >>> :315) > >>> at > org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > >>> at org.codehaus.classworlds.Launcher.mainWithExitCode( > >> Launcher.java > >>> :430) > >>> at > org.codehaus.classworlds.Launcher.main(Launcher.java:375) > >>> > >>> I'm not sure which project is wrong, as the spec does not say much > about > >> the > >>> id: well, it does not say that it does to be an integer, so I'm > leaning > >>> towards patching felix obr. > >>> > >>> Thoughts ? > >>> > >>> > >> > > > >
