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.
Currently the public classes of autoupdate module are available in org.netbeans.modules.autoupdate package. It would be nice to place them into org.netbeans.api.autoupdate & org.netbeans.spi.autoupdate as described in http://openide.netbeans.org/versioning-policy.html#2
Ales, if you agree and can please include this in features.xml for autoupdate module.
Target milestone was changed from '3.4' to TBD.
reassigne to Hrebejk, new owner of autupdate
reassigne to Jirka - new owner of autoupdate
It would be excelent if this new API would also remove the ide.ks file and replace it with layered alternative: http://www.netbeans.org/source/browse/openide/www/proposals/arch/installation.html.diff?r1=1.74&r2=1.75
if it's not *absolutely* necessary I would like to postpone the "official API" to after promo-d. Removing core-promod from this issue and set TM to "future"
*** Issue 26215 has been marked as a duplicate of this issue. ***
Created attachment 36912 [details] Javadoc and Arch document
Or browse directly at jar:http://wiki.netbeans.org/wiki/attach/AutoupdateAPI/org-netbeans-modules-autoupdate-services.zip!/index.html s/getUpdatesProviders/getUpdateProviders/ No Javadoc, so much to review yet. Is this an inception review?
Yes, it's a inception review. The attached zip file contains supported use-cases and some other answers to initial questions. Early implementation found in modules autoupdate/services and autoupdate/ui on branch autoupdate_19930.
Is this the list of issues that this proposal is addressing: http://www.netbeans.org/issues/showdependencytree.cgi?id=19930? Would these API & SPI be used by the Module Manager & Update Center wizard & perhaps the autoupdate extension client modules (that create new Update Centers for some major features in the IDE)? I'm not clear if this also addresses the ability to install a cluster / feature / a group of modules into the IDE? and more? Question on the Element.Style: there are these 3: FEATURE, LOCALIZATION, MODULE. Correct? Why 3 ? can an Element be both a MODULE & LOCALIZATION? Some mix and match? What's a localization style? When / how to use these different styles from the developer point of view? What would be the user experience for these? If possible, example? . Regarding feature, how can an UpdateUnit of FEATURE Style be defined / determined? what about the order of the dependencies to be installed? some examples? . Like to see example how we can define & subscribe our own update center? . Can the localized modules be installed separately? or need to be installed together with the base modules?
Thanks Chau for your comments. See my comments below. > Is this the list of issues that this proposal is addressing: > http://www.netbeans.org/issues/showdependencytree.cgi?id=19930? Would these API > & SPI be used by the Module Manager & Update Center wizard & perhaps the > autoupdate extension client modules (that create new Update Centers for some > major features in the IDE)? Yes, that parts of AutoUpdate feature will use them. > I'm not clear if this also addresses the ability to > install a cluster / feature / a group of modules into the IDE? and more? Yes, implementation of API in autoupdate/services module has capability to install/uninstall that. > Question on the Element.Style: there are these 3: FEATURE, LOCALIZATION, MODULE. > Correct? Why 3 ? can an Element be both a MODULE & LOCALIZATION? Some mix and > match? Element shouldn't mix more styles together. Each ELEMENT is only one style e.g. MODULE, FEATURE or LOCALIZATION, based of Update Center Descriptor (aka autoupdate_catalog.dtd) Note that UC Descriptor will be extended to fit all needs. > What's a localization style? When / how to use these different styles from the > developer point of view? What would be the user experience for these? If > possible, example? Ad developer point of view: it is not part of this proposal. Optionally, IDE could contain some supporting actions in Module Development Extension which helps to build these. Ad user experience: it depends of UI spec. of new Autoupate Client which is built on top of Autoupdate API as separate module (autoupdate/ui) > . Regarding feature, how can an UpdateUnit of FEATURE Style be defined / > determined? what about the order of the dependencies to be installed? some > examples? UpdateUnit|FEATURE is based on ELEMENT|FEATURE which comes from Autoupdate SPI. FEATURE covers group of modules. Autoupdate API offer FEATURE among available units when at least of one of feature's module can be installed. > . Like to see example how we can define & subscribe our own update center? One of ways to define Update Center is declare of your module layer. An user of IDE can subscribe own UC in Autoupdate UI. Note there will be an opportunity to plug own ELEMENT provider based on Autoupdate SPI. UC would be one of possible implementation of this SPI. > . Can the localized modules be installed separately? or need to be installed > together with the base modules? LOCALIZATION can be installed separately if no base module is present. If there is base module & its localization then will be installed together base on active locale. But, it also depends on AutoUpdate UI.
Some comments or missing services: JR01: SPI should give information about chosen UpdateUnit on demand. Autoupdate UI wants to sort unit by #download or #user's rating. It's a live data and cannot by contain directly in Update Center Descriptor but should be find out on demand. JR02: SPI should handle submit of user's rating or user's comments to dedicated storage server. JR03: Missing quality statement of UpdateUnit which describe if it's stable, security-important, beta or alpha quality. The quality should be signed by some authority, e.g. NetBeans QA signed.
Prepared opinions document for review meeting at http://openide.netbeans.org/tutorial/reviews/opinions_19930.html
There comments are not for inception, more for final review: Y01 UpdateManager should be non-subclassable Y02 There should be a pair class for UpdateProvider in API, maybe call it ProviderDescription Y03 UpdateProvider.getLicenses is somehow strange, should not be a license associated with UpdateItem? Maybe create License class. The class is probably also needed in API, so maybe move it there. Y04 Imho UpdateItem should have not public methods, they are only needed for the infrastructure, so please use Trampoline.SPI Y05 KeyStore problem: Keystores seem independent from UpdateProviders. They should be read from config/Autoupdate/Keystores or so Y06 I'd like UpdateProvider.getUpdateItems() to return just List<UpdateItem> not a map Y07 I want to delete all the interfaces and classes in SPI that subclass UpdateItem and replace them with a factory method. Imho there should be UpdateItem.createLocalization, UpdateItem.createFeature, etc. The classes can be there, but they should be used just internally See you tomorrow.
Open issues were added into opinions document http://openide.netbeans.org/tutorial/reviews/opinions_19930.html.
[JG01] "Friend, Private or Third Party" stability category is inappropriate for something using org.netbeans.[as]pi.** namespaces. [JG02] Can any methods in UpdateUnit return null? Do all the Element's available from a UU need to have the same Style? [JG03] Style should probably be a top-level enumeration with a distinctive name. <<something>>Type would be better, I think. [JG04] "Element" is a poor name (e.g. conflicts with org.w3c.dom.Element and javax.swing.text.Element). Maybe UpdateElement. [JG05] "call List<UpdateUnit> UpdateManager.getDefault().getUpdateUnits(UpdateStyle style)" - no such method exists. [JG06] "Client knows UpdateUnit and Version which wants to install." - what is a "Version"? "Create Install operation on the given unit: UpdateOperation.createInstallOperation(unit, version)" - you mean (unit,element)? [JG07] UpdateOperation is a final class. It should not have a protected method apply(). [JG08] Rather than e.g. UpdateOperation op = UpdateOperation.createDisableOperation(unit); UpdateManager.getDefault().prepareOperation(disableOperation); UpdateManager.getDefault().apply(); wouldn't it be simpler to have UpdateOperation op = UpdateManager.getDefault().createDisableOperation(unit); UpdateManager.getDefault().apply(); ? I don't see any reason why you would create an operation that you did not just immediately prepare anyway. Also I do not see when you would call cancelOperation, nor how you know "If all okay...". [JG09] UpdateOperation.createRollbackOperation(unit, version) - no such method exists. (Suggest you actually link to methods in Javadoc from your arch.xml; then you will also be warned by the build when they do not exist.) [JG10] UpdateProviderFactory.create(String,File...) - what is this? [JG11] UPF.create programmatically registers a factory. Does the SPI address registering one declaratively, e.g. through your XML layer? Or does that remain unspecified (i.e. have to use existing undocumented trick)? [JG12] Various methods in UpdateProviderFactory which take an UpdateProvider object look like they should simply be on the UpdateProvider, or the API "mirror" of it. [JG13] What is the 'unique-id' pref key? [JG14] Why is UpdateItem abstract with all methods final except for getId()? (How can you anyway subclass it if it has no accessible constructor?) What are the UI.* nested classes for? Why is UI.Module.getCustomInstaller() not specified in ModuleDescriptor? The whole SPI is a mystery to me.
We are going to integrate Autoupdate API/SPI into main trunk next week. The API/SPI is not fully implemented now but I think it's fitting quality needs to integration into CVS trunk and following development might be in trunk. There are known and reported problems against pre-merge-builds http://www.netbeans.org/issues/buglist.cgi?Submit+query=Submit+query&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=&short_desc_type=substring&long_desc=&long_desc_type=substring&issue_file_loc=&issue_file_loc_type=substring&status_whiteboard=plugin-manager&status_whiteboard_type=substring&keywords=&keywords_type=anytokens&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&namedcmd=rmdefects&newqueryname=&order=Reuse+same+sort+as+last+time, there is no blockers for integration. I'm going to attach ASAP the Javadoc of current API/SPI, most of RFE for inception-review has been implemented. The API/SPI will be still in under-development quality, some changes are expected. I would like the final review for stable quality on the end of NB6 or soon in the sequent release. Thanks.
Created attachment 40562 [details] Autoupdate API/SPI for integration to trunk
The API is part of 6.0 official namespace and has to be stabilized by 6.1. Setting milestone. Needs to be tracked. Making P2 defect.
changeset: 77062:806004237ffb user: Jaroslav Tulach <jtulach@netbeans.org> date: Mon Apr 07 13:47:02 2008 +0200 summary: Showing just stable modules in the list of javadocs, making all that are visible there stable