This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 210281

Summary: changes in osgi bundles aren't always provided for download from UC
Product: platform Reporter: Tomas Stupka <tstupka>
Component: AutoupdateAssignee: Libor Fischmeistr <lfischmeistr>
Status: REOPENED ---    
Severity: normal CC: jglick, jtulach
Priority: P2 Keywords: API
Version: 7.2   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:

Description Tomas Stupka 2012-03-28 13:33:40 UTC
the plugin manager provided updates of an osgi bundle given by the Bundle-Version value taken from it's manifest. This unfortunately doesn't work well in some scenarios:

1.) a bundle has to be downgraded for some reason => Bundle-Version on the UC is obviously lower than from the installed bundle

2.) when a bundles manifest (generated by the wrapping modules build script) was changed - e.g. javax.xml.soap => the bundle version stays the same, though the manifest changed.
Comment 1 Jaroslav Tulach 2012-03-28 13:51:52 UTC
As far as #2 goes, I'd suggest to use the OSGi text after 3rd dot (which can be any text) as a 4th number (if it is a number). Autoupdate would just have to pay attention to it and use it if available. Whenever we would like to publish a patch, we'd specify (or increment) the 4th digit.
Comment 2 Jesse Glick 2012-03-28 20:12:41 UTC
#1 applies to any module; AU does not support downgrading.


For #2, I doubt anything special needs to happen in infrastructure:

diff --git a/javax.xml.soap/build.xml b/javax.xml.soap/build.xml
--- a/javax.xml.soap/build.xml
+++ b/javax.xml.soap/build.xml
@@ -6,7 +6,7 @@
             <zipfileset src="external/saaj-1.2.0.jar"/>
             <manifest>
                 <attribute name="Bundle-SymbolicName" value="javax.xml.soap"/>
-                <attribute name="Bundle-Version" value="1.2.0"/>
+                <attribute name="Bundle-Version" value="1.2.0.1"/>
                 <attribute name="Export-Package" value="javax.xml.soap;version=&quot;1.2.0&quot;"/>
                 <attribute name="Import-Package" value="org.w3c.dom"/>
             </manifest>

or am I missing something?
Comment 3 Tomas Stupka 2012-03-28 20:33:09 UTC
(In reply to comment #2)
> #1 applies to any module; AU does not support downgrading.
with an external library provided via external/binaries-list you replace the binary in the list with an older version and raise the nb module version. This isn't posible in case of an osgi bundle.
Comment 4 Jiri Rechtacek 2012-07-25 05:39:34 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > #1 applies to any module; AU does not support downgrading.
> with an external library provided via external/binaries-list you replace the
> binary in the list with an older version and raise the nb module version. This
> isn't posible in case of an osgi bundle.

Is it still a problem? I don't know what I should fix there.
Comment 5 Tomas Stupka 2012-07-25 06:46:10 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > #1 applies to any module; AU does not support downgrading.
> > with an external library provided via external/binaries-list you replace the
> > binary in the list with an older version and raise the nb module version. This
> > isn't posible in case of an osgi bundle.
> 
> Is it still a problem? I don't know what I should fix there.
it will be in problem once we will have to place on the UC a lower version as there already is. With other words - we have no way how to replace (downgrade)) e.g. a regressing library
Comment 6 Jaroslav Tulach 2012-08-09 10:00:37 UTC
We don't have a way to downgrade NetBeans modules either. We can only provide newer updates. There is no reason to request downgrades from OSGi bundles. Just fix what is necessary and release an update.

When there is a fix in an OSGi bundle and it does not change its specification version, we should have a way to deliver it to users. As Jesse suggested, using fourth digit might do the trick.

When in total despair, you could potentially downgrade from 1.2 to 1.1 and just call the old version "1.2.0.1-downgraded-to-1.1", imho.