NB6AutoupdateChangesJesseAnswer
Jaroslav Tulach wrote:
> I have to point out that I've been proposing 4d:
For the record, Pavel's original proposal was badly underspecified in
terms of AU client semantics (IMO) and I am not confident I grasp the
meaning of either Trung's counterproposal (4a?) or whatever it is you
are proposing here (much less Radek's 4e which is completely new to me).
If you want me to intelligently review your idea, I would need a
complete written proposal (not an email exchange or conf call, nor diff
from some other proposal) that specifies at least:
1. What, if any, NBM and/or UC.xml format changes are required relative
to NB 5.x; including both actual format changes (new manifest attrs, DTD
changes) and changes in conventional usage (e.g. special meaning of
display category etc.).
2. Definition of which entities (modules, kits, features, ...) are
displayed in the PM dialog and what controls this selection.
3. Exact semantics of enable and disable operations for all visible
entities, given in some kind of pseudocode, taking into account autoload
and eager modules as appropriate.
4. Exact semantics of install and uninstall operations for all entities,
again taking into account autoload and eager modules (and paying special
attention here to the fact that the current UC.xml format does not
distinguish autoload and eager modules so this information is currently
missing for modules which have not yet been installed).
5. Treatment of low-level modules with UI which we would probably prefer
users never manipulate or perhaps even see, e.g. Project UI or Window
System.
6. Impact, if any, on RCP applications which use mostly platform-cluster
modules; including both those which bundle PM (.au.ui module?) and those
which do not.
7. Special steps required, if any, by developers of extra standalone
modules to be placed on AU, e.g. Mercurial support or Ant Manual; and
compatibility implications for developers who ignore or are unaware of
our PM changes.
8. Special steps required by developers of larger suites of
functionality to be placed on AU, e.g. Collaboration support, which we
would prefer to display as a single entity.
9. Relationship to installer components, and expected UI of either
removing a whole installed component, or adding a new installer
component (e.g. Ruby Support) using PM.
10. Detailed examples of the new logic in action, using actual modules
in our IDE (or update centers) for illustration.
We are, after all, well after nominal feature freeze for 6.0, and
everyone is throwing around proposals, most of which seem to involve
rather significant semantic changes in how users interact with installed
and available modules in the IDE. We cannot afford to be vague here.
-J.
--
jesse.glick@sun.com netbeans.org ant.apache.org hudson.dev.java.net
http://google.com/search?q=e%5E%28pi*i%29%2B1
Trung replayed:
Jesse Glick wrote on 07/13/2007 04:49 PM:
> Jaroslav Tulach wrote:
>> I have to point out that I've been proposing 4d:
>
> For the record, Pavel's original proposal was badly underspecified in
> terms of AU client semantics (IMO) and I am not confident I grasp
> the meaning of either Trung's counterproposal (4a?) or whatever it is
> you are proposing here (much less Radek's 4e which is completely new
> to me). If you want me to intelligently review your idea, I would
> need a complete written proposal (not an email exchange or conf call,
> nor diff from some other proposal)
fair enough. But I try to explain what I mean by 4a) in email anyway
because I am gone the whole next week.
(4a) must be combined with (3). It's meaningless by itself
A kit in (3) is a normal module which declares dependency on other
modules. Installing a kit will force other modules it depends on to be
installed. The trick we used for Developer Collaboration, or Ruby. The
kit is not strictly necessary. We use it only if we have a larger
collection of modules which we want to present to users as a single
item. It's not a new kind of module. Running
ant -f $proj/build.xml fix-dependencies
on it will report bunch of unused dependencies. We can also use one of
the exiting modules in that collections to play that role if it feels
natural and has dependencies on all the other modules in that collection.
(The word collection could be misleading for this discussion. It's OK
for Ruby, but collection is not essential. The users want a feature, we
just have to give them a module to click on to get that feature
installed, all modules to form that feature and modules those modules need)
It would work like this:
Assume we have modules A, B, and C, they can depend on other modules.
They can be autoload, eager or regular. We want to present these three
as one single unit in the Plugin Manager. To do it one would mark all
three with
OpenIDE-Module-Show-In-AutoUpdate-Client: false
Then create a new module K and makes it depends on A, B and C. That way
in the Installed tab only K will be shown.
Operations on K:
* install: the user doesn't have K in the IDE yet. He chooses K to be
installed. Because of dependencies A, B, and C will also be installed.
Because A, B and C are "invisible" the Plugin manager will be silent
about them
* deactivate K: Plugin Manager figures out all modules K depends on,
directly and indirectly to form a set of modules. A, B and C certainly
belongs to this set. It excludes all modules which don't have the
attribute OpenIDE-Module-Show-In-AutoUpdate-Client set to true. It then
excludes all modules used by modules outside of that set. Then disables
all the rest. That way only K and unused invisible modules are disabled.
* activate K: similar to install operarion
* uninstall K: similar to deactivate operation
This scheme only affects how Plugin manager collects a set of modules to
be installed, enabled or disabled. Semantics of autoload, regular and
eager modules should be respected as before in 5.5.
> that specifies at least:
>
> 1. What, if any, NBM and/or UC.xml format changes are required
> relative to NB 5.x; including both actual format changes (new
> manifest attrs, DTD changes) and changes in conventional usage (e.g.
> special meaning of display category etc.).
<manifest> element will have one new attribute, e.g
<module ...>
<manifest OpenIDE-Module-Show-In-AutoUpdate-Client="false" .../>
</module>
>
> 2. Definition of which entities (modules, kits, features, ...) are
> displayed in the PM dialog and what controls this selection.
there are only modules. If the module has
OpenIDE-Module-Show-In-AutoUpdate-Client: false
in its manifest then don't show. Otherwise show
>
> 3. Exact semantics of enable and disable operations for all visible
> entities, given in some kind of pseudocode, taking into account
> autoload and eager modules as appropriate.
see above. Autoload and eager could even be shown and operated upon if
the developer chooses to set OpenIDE-Module-Show-In-AutoUpdate-Client to
true. For existing modules out there, it's in fact the default. Only
this attribute controls visibility of a module in the PM. The lack of
it means "show". We try to follow least-astonishment principle.
>
> 4. Exact semantics of install and uninstall operations for all
> entities, again taking into account autoload and eager modules
if a module is visible, the same semantics as in 5.5 applies.
If a module is invisible then an operation on it is triggered by the
same operation on a visible module which depends on it. Semantics of
those operations stay the same
> (and paying special attention here to the fact that the current
> UC.xml format does not distinguish autoload and eager modules so this
> information is currently missing for modules which have not yet been
> installed).
autoload and eager module property is not used here. No change
>
> 5. Treatment of low-level modules with UI which we would probably
> prefer users never manipulate or perhaps even see, e.g. Project UI or
> Window System.
all those modules will be marked with
OpenIDE-Module-Show-In-AutoUpdate-Client: false
This attribute only influences behavior of PM and has no meaning
elsewhere. A visible Platform "kit" module is not needed because we
don't show Platform at all in PM. The user has no reason to disable
Platform. Currently they can disable autoupdate in NBM view mode. All
power to the people :-)
>
> 6. Impact, if any, on RCP applications which use mostly
> platform-cluster modules; including both those which bundle PM
> (.au.ui module?) and those which do not.
If an RCP app picks one of our modules and also wants to use our PM
(probably with a different set of preregistered UCs) it has to inherit
the visibility property of that module. No way to override it. This
may be a weakness of this proposal. But I honestly can't think of a
good example.
<side note>
Also note that reusing only a subset of modules in a cluster already has
certain problems like
* if the RCP app developer rebuilds his app against the next version of
the cluster and if that cluster contains new modules those new modules
will appear in the RCP app.
Tor's rubyide was caught by this problem. Luckily he had hudson c/b
which builds against latest trunk c/b
</side note>
>
> 7. Special steps required, if any, by developers of extra standalone
> modules to be placed on AU, e.g. Mercurial support or Ant Manual; and
> compatibility implications for developers who ignore or are unaware
> of our PM changes.
They can ignore what we said here. In fact for simple modules that's
completely OK. For advanced folks who have a collection of modules and
want to group them somehow they would use the technique described here.
(For a single feature people usually don't need more than one module.
During my days at nbextras.org only Sandip did it. A separate wrapper
module for an external lib like apache common-* is a typical case where
more than one module is desired.)
Since we will also show the category column in PM, outside developers
are recommended to choose a sensible existing category to place their
modules in. A concept of "well-known" categories. What we have now is
a mess and should be cleaned up. I talked about it in the previous email
>
> 8. Special steps required by developers of larger suites of
> functionality to be placed on AU, e.g. Collaboration support, which
> we would prefer to display as a single entity.
keep the kit module as is, set all other modules to be invisible in AU,
rebuild, submit *.nbm, a catalog is regenerated like in 5.5. Done
>
> 9. Relationship to installer components,
installer component names => category names in PM
> and expected UI of either removing a whole installed component,
select all modules in the same category and uninstall
> or adding a new installer component (e.g. Ruby Support) using PM.
select all modules in the same category and install
Note: the list of modules shown in PM is more than what the installer
offers because we combined all modules from all UCs. For example
mercurial will show up in the same category as svn and cvs and the user
doesn't know that cvs and svn are from NB standard and mercurial is not.
But why they should care if mercurial works?
cvs, svn, hg,.. may deserve their own category "Version Control" in PM
but the there is a strong desire at this moment to have direct mapping
from installer components to something in PM and I can hardly imagine we
can expose 20 components in the installer
>
> 10. Detailed examples of the new logic in action, using actual
> modules in our IDE (or update centers) for illustration.
well :-)
If you want every details than I can't do it now. Ruby would be too
easy. But let pick a harder example
Say I have only Ruby installed, ie ide*/ and ruby*/, no java. Later on
I want to play with matisse because people keep talking how cool it is.
After a lot of googling, searching and head scratching and finally
posting questions to nbusers I figured out that it's in fact called
"Form Editor". I select it in the list of New Plugins ("New? I thought
matisse exists since 5.0? Nevermind") and tell the IDE to install it.
After analyzing module dependency PM says to install "Form Editor" I
also need to install a few more plugins. It's silent about those
modules marked with "don't show me in AU client". I say yes, go ahead.
All nice and good. A few minutes later I have it installed. Because I
am reading the tutorial on netbeans.org I try to create a sample app
according to the tutorial. But because the sample apps is packed in a
different module which the form editor doesn't depends on and thus not
installed, I said to myself "WTF" and decide to uninstall Matisse. But
before that I somehow manage to created a java app project and did a
simple hello world form.
I go back to PM, still vaguely remember that it told me which additional
plugins I had to install to get "form editor" working so i select them
("wow, multiple select doesn't work"). I click on Uninstall, after
sometime I ended up with NPE and things like that because I didn't know
NetBeans modules especially the more sophisticated one like form editor
doesn't like to be disabled on the fly
-%--%--%--%-
Seriously, I am very scared with deactivate/uninstall modules on the
fly. Try it yourself. Be prepared that to be safe we'll have to
restart the IDE whenever the users disable/uninstall modules (a la
Firefox). This would affects UI of PM.
This is not the fault of the module system per se, and it's not new bug
but what used to be P6 in 5.5 now will be at least P2 in 6.0 and there
would be a lot of them. They already are with the current trunk build
but not filed in IZ yet. We can't hope our developers can fix their
500+ modules in short time to make them smoothly uninstallable, incl.
performance issue. Deactivating modules takes incredibly amount of time
for my taste and sometime consumes a lot of mem for no justifiable
reasons, at least from user point of view.
-t
Some further comments from Jesse:
Trung Duc Tran wrote: > [AKitIs] not a new kind of module. Running > > ant -f $proj/build.xml fix-dependencies > > on it will report [A] bunch of unused dependencies. Not true. This kind of dependency would be runtime-only, which is ignored by fix-dependencies. Trung Duc Tran wrote: > * deactivate K: Plugin Manager figures out all modules K depends on, > directly and indirectly to form a set of modules. A, B and C certainly > belongs to this set. It excludes all modules which don't have the > attribute OpenIDE-Module-Show-In-AutoUpdate-Client set to true. It then > excludes all modules used by modules outside of that set. Then disables > all the rest. That way only K and unused invisible modules are disabled. > > [....] > > all [Platform] modules will be marked with > > OpenIDE-Module-Show-In-AutoUpdate-Client: false ...which by the above rule means they would sometimes be silently deactivated, unless there is some other as-yet-unstated rule. Trung Duc Tran wrote: > If the module has > > OpenIDE-Module-Show-In-AutoUpdate-Client: false > > in its manifest then don't show. Otherwise show > > [...] > > Autoload and eager could even be shown and operated upon if > the developer chooses to set OpenIDE-Module-Show-In-AutoUpdate-Client to > true. This seems contradictory. (1) If the lack of OIDE-M-S-I-AU-C=false means to show, then why would you ever set OIDE-M-S-I-AU-C=true? (2) If an autoload or eager module is displayed, what could you do with it? You certainly cannot directly enable or disable it. Trung Duc Tran wrote: > Say I have only Ruby installed, ie ide*/ and ruby*/, no java. Later > on I want to play with matisse because people keep talking how cool > it is. [...] > > After analyzing module dependency PM says to install "Form Editor" I also need to install a few more plugins. [...] I somehow manage to > created a java app project and did a simple hello world form. Except you won't manage, since there will not be any j2seproject if you have just installed form and its dependencies. Maybe you will figure out that you also need to select "Java SE Projects" or whatever we wind up calling it. (It is definitely wrong for form to dep on j2seproject since you can also use the form editor on many other project types.)
