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 19930 - Create an official API for autoupdate module
Summary: Create an official API for autoupdate module
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Autoupdate (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: apireviews
URL: http://openide.netbeans.org/tutorial/...
Keywords: API, API_REVIEW, ARCH
: 26215 (view as bug list)
Depends on: 54668 90188 90191 90192 95934
Blocks: 31062 89627
  Show dependency tree
 
Reported: 2002-01-30 08:50 UTC by Jaroslav Tulach
Modified: 2008-04-10 18:07 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Javadoc and Arch document (193.33 KB, application/x-compressed)
2006-12-22 19:42 UTC, Jiri Rechtacek
Details
Autoupdate API/SPI for integration to trunk (1.37 KB, application/octet-stream)
2007-04-06 16:02 UTC, Jiri Rechtacek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2002-01-30 08:50:47 UTC
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
Comment 1 Jaroslav Tulach 2002-01-30 08:51:29 UTC
Ales, if you agree and can please include this in features.xml for
autoupdate module.
Comment 2 Marek Grummich 2002-07-22 08:24:43 UTC
Target milestone was changed from '3.4' to TBD.
Comment 3 Marian Mirilovic 2002-12-06 18:50:10 UTC
reassigne to Hrebejk, new owner of autupdate 
Comment 4 Marian Mirilovic 2003-12-01 10:49:25 UTC
reassigne to Jirka - new owner of autoupdate
Comment 5 Jaroslav Tulach 2004-04-01 14:53:40 UTC
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

Comment 6 _ ttran 2004-04-14 13:07:37 UTC
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"
Comment 7 Jiri Rechtacek 2006-11-28 13:18:56 UTC
*** Issue 26215 has been marked as a duplicate of this issue. ***
Comment 8 Jiri Rechtacek 2006-12-22 19:42:46 UTC
Created attachment 36912 [details]
Javadoc and Arch document
Comment 9 Jesse Glick 2007-01-05 21:46:24 UTC
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?
Comment 10 Jiri Rechtacek 2007-01-05 22:10:01 UTC
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.
Comment 11 Ch Nguyen 2007-01-15 22:36:43 UTC
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?


Comment 12 Jiri Rechtacek 2007-01-16 09:04:57 UTC
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.
Comment 13 Jiri Rechtacek 2007-01-16 15:17:53 UTC
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.
Comment 14 Jiri Rechtacek 2007-01-17 16:05:15 UTC
Prepared opinions document for review meeting at
http://openide.netbeans.org/tutorial/reviews/opinions_19930.html
Comment 15 Jaroslav Tulach 2007-01-17 17:24:59 UTC
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.
Comment 16 Jiri Rechtacek 2007-01-18 13:12:13 UTC
Open issues were added into opinions document
http://openide.netbeans.org/tutorial/reviews/opinions_19930.html.
Comment 17 Jesse Glick 2007-01-18 15:51:34 UTC
[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.
Comment 18 Jiri Rechtacek 2007-04-06 12:54:38 UTC
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.
Comment 19 Jiri Rechtacek 2007-04-06 16:02:32 UTC
Created attachment 40562 [details]
Autoupdate API/SPI for integration to trunk
Comment 20 Jaroslav Tulach 2007-12-11 08:19:40 UTC
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.
Comment 21 Jaroslav Tulach 2008-04-10 18:07:33 UTC
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