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
Ales, if you agree and can please include this in features.xml for
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:
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
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
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
. Regarding feature, how can an UpdateUnit of FEATURE Style be defined /
determined? what about the order of the dependencies to be installed? some
. 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
> 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
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
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
JR02: SPI should handle submit of user's rating or user's comments to dedicated
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
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
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
[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
[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
[JG08] Rather than e.g.
UpdateOperation op = UpdateOperation.createDisableOperation(unit);
wouldn't it be simpler to have
UpdateOperation op = UpdateManager.getDefault().createDisableOperation(unit);
? 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
[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
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.
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.
user: Jaroslav Tulach <firstname.lastname@example.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