1) Granularity of user visible plugins listed in available and installed
lists

as described in Pavel's document.

The categories are important and should be documented in dev howto
somewhere, ie having a list of "well-known" categories, so that 3rd
party who implements a module, say, to support ClearCase, will put it
under the same category we put our CVS, Subversion and Mercurial

The list of plugins, their names, and categories in Pavel's proposal
will have to go through several iterations but the basic idea is
correct.  It speaks in term of features the users care about.

OWNER: Pavel to define the final list and get it reviewed and
implemented, for all modules in NetBeans and also supervise what gets
into stable update center

--%----%----%----%----%----%--

2) Updates

If updates are available we inform the users and let them decide to
update now or later.  All or nothing.  No checkboxes.  We agreed that
the download size and changelog are the most important information at
that moment, not the list of modules being updated.  Showing the
description of the modules without showing the changelog is weird.
But displaying changelog will not be implemented in 6.0, we are out of
time.  Showing the changelog shouldn't be a big deal, having a changelog
from all updated modules is a big logistic headache and would need time
for our developers to practice.  I also don't even want to think about
localization of changelog at this moment

If no updates are available we should move the Updates tab somewhere
else.  This tab is empty most of the time, so it should not be selected
when the user opens the Plugin Manager.  OTOH if updates are available
this is the most important information and should be highlighted

OWNER: Jano to come up with the new UI.  Keep it simple

OWNER: Jirka/Radek to implement it

--%----%----%----%----%----%--

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, nothing
special has to be done in generating that catalog.  Back to pre-6.0
state.  No <feature> element in DTD

This makes many of the open issues listed in

http://wiki.netbeans.org/wiki/view/NB6PluginManagerIssues

irrelevant.  That document lists several issues which still need to be
resolved like setting file permissions (e.g. jruby executables).  They
are not related to the changes we do in AU client per se

--%----%----%----%----%----%--

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

4a) An explicit flag in module manifest to indicate that module not to
be shown in AU UI

OpenIDE-Module-Show-In-AutoUpdate-Client: [true | false]

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

4b) An explicit flag in *another* module (perhaps the kit module) to
turn on/off visibility of the other modules.

4c) Overload the meaning of module category.  If the category is empty
string or "Library" then do not show

DECISION: we go with 4a

TASKS

* Without any work anywhere else the developer can just go ahead and put
this new attribute in <module>/manifest.mf but it would be better if we
do it this way

  extend the module build infrastructure (ie harness) so that it looks
  for a property "show.in.autoupdate.client=true/false" in
  nbproject/project.properties and generates the corresponding
  OpenIDE-Module-Show-In-AutoUpdate-Client: [true | false] in
  MANIFEST.MF

  If show.in.autoupdate.client is missing then generates true (show) for
  regular modules and false (hide) for autoload modules.  I feel that
  eager modules should be shown by default

  Of course if the developer already specifies
  OpenIDE-Module-Show-In-AutoUpdate-Client in <module>/manifest.mf then
  it takes precedence

  validate-catalog ant task should be adapted accordingly to recognize
  this new manifest attribute

OWNER: Jesse

* Enhance apisupport to show a corresponding checkbox in module's
project customizer and generates

OWNER: Jesse

* Dev documentation

OWNER: Jesse

* AU client looks for this new attribute in
module.jar:/META-INF/MANIFEST.MF, catalog.xml or info.xml and behaves
accordingly

OWNER: Jirka/Radek

--%----%----%----%----%----%--

5) Special case for modules in platform cluster

Do not show in AU.  Just Platform

(I am not completely sure about javahelp and swing-layout but if I have
to decide now, I would stick with "don't show")

Implementation-wise: it's probably easier and less work if AU client
just looks for the cluster name and if it's platform* then make a
special case.  But it's a bit irregular.  No strong opinion

We also have a short list of "fixed" modules, they all belong to
platform.  Don't show

--%----%----%----%----%----%--

5) How to deal with updates of "invisible" modules

Walk the dependency tree of currently installed modules and show all the
nearest visible ancestors.  Not just one ancenstor, walk up the tree,
If there is no ancestor then we have to ignore the flag above and show
it. (Up or down, ancestor or descendant depends on how we draw the
tree  :-) 

But a few paragraphs above we said we won't let users to choose which
modules to update and which not, so "show" here only means static text
describing what's going to be upgraded

--%----%----%----%----%----%--

6) Manual install

We have to show all modules even when the "don't show me" flag is
present.  Those modules then won't show up in the list of installed
modules.  Bug but P3 for 6.0 I think

--%----%----%----%----%----%--

7) Activate/deactivate, install/uninstall

I think the logic stays the same as of now.  Even though in term of code
the list of modules which forms a "feature" will have to be constructed
the other way.  See Grouping section

--%----%----%----%----%----%--

8) Relationship b/w modules shown in AU and components shown in installer

Component names in installer should be used as category names in AU

(I have strong temptation to move xml1/ out of base ide component and
thus out of "basic" download option.  ruby and c/c++ are not that
excited about wsdl, cannot rule out it won't happen in 6.0)

--%----%----%----%----%----%--

9) Plugin and NBM View Modes

Gone.  Only one mode.  Implementation wise it's will be the NBM mode.
We have to show category column

--%----%----%----%----%----%--

10) Origin of modules in New Plugins

Pavel's proposal also talks about things like Plugin Portal UC.  I
haven't thought enough about it and we didn't discuss it in the meeting.
 For now enough to say it's somewhat orthogonal.  Personally the biggest
showstopper I have now for Plugin Portal UC is those modules have zero
if not negative quality.  Many of them don't even install in 5.5 for me

--%----%----%----%----%----%--

11) Getting stats about which components are implemented

This was mentioned somewhere if we break the 1-1 mapping b/w installable
components in installer and installable units in AU then it's impossible
to get stats about which components are installed by users.

Well, we don't optimize for stats

--%----%----%----%----%----%--

11) We need all above implemented for beta1

Because of the current bug situation I know beta1 will move, this gives
us a little more time.  There is some additional work required but the
changes described here also turn some existing code into dead code and
serious open issues into irrelevant so I hope they cancel out each other

--%----%----%----%----%----%--

Hope I haven't forgot anything important and you have enough to proceed
with the work.

THANKS

	-t

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...