NB6AutoupdateChangesJardaAlternative
On Jul 13, 2007, at 1:12 , Trung Duc Tran wrote: > Someone or me (preferably someone) needs to incorporate what we said > here into the document in wiki. We need to let nb-tech and other > people know about this plan. I'll be locked down in meetings the > next week. So please... If you tell me where to put it, I can. > > 3) How grouping should be implemented > > We agreed to use the "kit" module or pick an existing module which > naturally fits this purpose. Per Pavel's proposal > > This means nothing special has to be done to the UC catalog, Well, we need to enhance the format to contain the new attribute. You wrote that in next section yourself. > nothing special has to be done in generating that catalog. Back to > pre-6.0 state. Right. My understanding is that the goal is: No changes in apisupport's or netbeans build infrastructure build scripts to generate new catalog with "kits". However of course, we are allowed to enhance the MakeNBM task to handle the new attribute. > 4) How to flag a module not to be shown in the AutoUpdate client UI > > We agreed that it's not a good idea to overload the meaning of > "autoload". We even have examples of modules which should be shown > in AU UI but must be regular modules not autoload for technical > reasons. > > So we will use an explicit "flag" for this purpose. > > Several alternatives were discussed I have to point out that I've been proposing 4d: An explicit flag in module manifest to indicate that a module is "kit". OpenIDE-Module-Kit: [False] the autoupdate client then show just "kit" modules, plus modules which are not needed (probably recursively) by any "kit". Example KitA needs X, Y KitB needs X, Z B needs X, Z X needs U Y needs V W needs U, Y In this situation the autoupdate client shows KitA, KitB, B, W. Also, I need to point out that "kit" modules are not just visible, but also have special treatment when disabling and uninstalling. If you uninstall KitB in the above example, that means the autoupdate client is supposed to uninstall KitB, the autoupdate client is supposed to uninstall KitB as well as Z, because Z is not needed by anyone else than the KitB. This is different than behaviour of uninstalling regular module B. If user uninstall B, it means that the client uninstall just B not Z. This is already implemented (Jirka, Radek correct me if I am wrong). Uninstalling/disabling feature is something different that just disabling a module. We know this works, we just need to find out if a module is regular one or feature/"kit". > 4a) An explicit flag in module manifest to indicate that module not > to be shown in AU UI > > OpenIDE-Module-Show-In-AutoUpdate-Client: [[False| true ]] > > This attribute is retained after the module is installed and gets > propagated into NBM's info.xml and UC catalog xml. The AU client has > enough information to decide to show or not to show This proposal does not specify how we find out that a module is regular one or if it is a "kit". This needs to be specified, if we want to go with 4a). > 4b) An explicit flag in *another* module (perhaps the kit module) to > turn on/off visibility of the other modules. Silly. > 4c) Overload the meaning of module category. If the category is > empty string or "Library" then do not show Again we need a way to find out a module is "kit" or just a regular module. Yesterday afternoon we also find out that 4d has a certain drawback. By turning the "kit" on, one effectively turns all all its dependencies, including autoloads, which may not be appropriate. Definitely in case of platform, that contains few autoloads for backward compatibility, which are usually off and one eager module that depends on MacOSX. j2ee used to contain deprecated unused autoload ddapi as well. There is a fix: the "kit" in 4d proposal would have to be autoload. However Radek proposed some other solution: 4e) An explicit flag in module manifest to define a "kit". Its meaning would be the same as with OpenIDE-Module-Dependencies, just it would not be understood by module system, just by autoupdate client. OpenIDE-Module-Define-Kit: org.netbeans.jruby.debugger, org.netbeans.jruby.profiler, org.netbeans.jruby.editor > > DECISION: we go with 4a > I'd like us to give this few more thoughts. Plain 4a is not enough, we need to find out if a module is a "kit" or a regular one. Moreover we did not really think about 4d and 4e during the meeting. I admit, my preference is 4d, because it requires minimal changes to the "UI": One can create a "kit" module using our wizard, one can add dependencies to the module using our project customizer, one just needs to go to the manifest.mf and add OpenIDE-Module-Kit: true, which is easy to do and explain. Implementation complexity of current 4a and 4d is the same - e.g. one attribute in manifest and in catalog xml. Maybe we can implement both 4d and 4a at once. That would work as well, I guess, keeping most of the proposal intact. Can we think about this more? Thanks. -jst
Minor correction:
On Friday 13 of July 2007 09:52:43 Jaroslav Tulach wrote: I need to split the example into two to really make sense, sorry: > Example: > > KitA needs X, Y KitB needs X, Z X needs U Y needs V W needs U, Y > > In this situation the autoupdate client shows KitA, KitB, W. > > Also, I need to point out that "kit" modules are not just visible, > but also have special treatment when disabling and uninstalling. If > you uninstall KitB in the above example, that means the autoupdate > client is supposed to uninstall KitB, the autoupdate client is > supposed to uninstall KitB as well as Z, because Z is not needed by > anyone else than the KitB. > Example2 where KitB is replaced by regular module B: > > KitA needs X, Y B needs X, Z X needs U Y needs V W needs U, Y > > In this situation the autoupdate client shows KitA, B, W. Now the > behaviour of uninstalling regular module B is different. If user > uninstalls B, it means that the client uninstalls just B not Z. The rest of the message remains the same. Sorry, I made later changes to the first and correct version of the example in order to demonstrate the different between KitB and B and only later realized that Z is needed by both B and KitB. -jst
