Bug 210281 - changes in osgi bundles aren't always provided for download from UC
changes in osgi bundles aren't always provided for download from UC
Status: REOPENED
Product: platform
Classification: Unclassified
Component: Autoupdate
7.2
All All
: P2 (vote)
: TBD
Assigned To: Libor Fischmeistr
au-issues
: API
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-28 13:33 UTC by Tomas Stupka
Modified: 2014-02-10 14:15 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo