Bug 136903

Created attachment 62613 [details]
javadoc

related issue: 115365

related issue: http://www.netbeans.org/issues/show_bug.cgi?id=115365

Created attachment 62620 [details]
Updated javadoc

Y01 Please generate code coverage for the API and attach it here.
Y02 How this module co-exits with old PrintCookie?
Y03 No usecases. Fix that.
Y04 use <api type="export" group="java" .../> to export the API, more info at 
http://openide.netbeans.org/tutorial/api.html

that is probably enough for now. 

Y01: Could you please clarify how to generate code coverage for the API?

Y03: What about usecases, do you mean usecases from user point of view
(how to invoke Print Preview dialog, how to print, options overivew)
or usecases from developer point of view (what code should be added
to available print/preview functionality in developer's module)?

Y01 How can I generate code coverage for the API?
Y03 usecases: fixed.
Y04 export the API: fixed.

Y02 How this module co-exits with old PrintCookie?

If selected node has PrintCookie and there is no available
print provider (org.netbeans.modules.print.spi.PrintProvider),
Print Preview action invokes method printCookie.print().

So, if customer writes own print cookie, it will work with new api too
(this behaviour was implemented as a request from a customer,
see issue http://www.netbeans.org/issues/show_bug.cgi?id=115769,
message from yaroslavskiy Wed Sep 19 11:36:04 +0000 2007, item 2).

Created attachment 62657 [details]
Updated javadoc

As to code coverage: all classes and methods from print.api are covered by junit tests.

To measure code coverage use "ant coverage" in print/test. This used to work, I am not sure if it still works.

coverage was added, see attached coverage.zip

Created attachment 62873 [details]
Coverage

[JG01] I dislike the use of Printable.class as a key when the value is a String. Conventionally, Class-typed keys should
be paired with instances of that class, where the meaning of the key is immediately apparent from the type. Would prefer
a String key describing its function, e.g. "print.header".


[JG02] "If empty name is passed, the display name of the top component is shown." - this seems hackish. Why not use the
TC.displayName by default if the key is not set at all? Or rely on the TC impl to call setClientProperty (or override
getClientProperty) with an appropriate label? If neither is desirable, please consider a separate key instead, such as
"print.header.automatic" = Boolean.TRUE.


[JG03] "If the data is a Swing component which extends javax.swing.JComponent and is shown in a
org.openide.windows.TopComponent" - this is confusing. You are supposed to set the client property on some random
component inside the TopComponent? Not on the TopComponent itself?


[JG04] Use class="nonnormative" CSS styling in Javadoc (e.g. on <p> or <div>) for informational text which is not part
of the guaranteed contract of the module, e.g. "The Print manager is powerful functionality .... and system properties."
Such text will appear with a blue background.


[JG05] Please do not use Dimension.class and Integer.class as keys for anything; this makes for unreadable code. Use
e.g. "print.size" (and clarify what the difference between "visual dimension" and "print dimension" actually means!),
and "print.order" (and fix the example which seems to be missing the variable "weight").


[JG06] Use {@link PrintProvider} rather than saying textually "(see <code>PrintProvider</code>)" and later "@see
PrintProvider".


[JG07] PrintProvider.getPages is badly underdocumented. In what units are "width" and "height"? What values can "zoom"
take on? What do the axis in the returned 2D array represent? What is the "given option"?


[JG08] What does PP.getName do? What does getLastModifiedDate do? Don't try to explain it to me in comments to this
issue - think about the poor reader trying to understand your API and write your Javadoc carefully and explicitly.
Example of bad Javadoc:

Date getLastModifiedDate()
    Returns date of last modification.
    Returns:
        date of last modification

Better might be (I am just making up a semantics for the method!):

Date getLastModifiedDate()
    Indicates the time at which the user last made a modification to the document, diagram, etc. being printed which
might affect its printed appearance. The document might not have been saved since then.
    Returns:
        time at which the printable document was last changed


[JG09] PrintManager.getDefault() does not seem useful, since it is a singleton anyway and there is no apparent reason
why it would ever not be a singleton. Suggest deleting getDefault and just making getPrintPreviewAction static
(preferably renamed "printPreviewAction" for consistency with other action factories).


[JG10] Should probably remove reference to "data object" from specification of which lookups are consulted. DataNode's
by default delegate to the DataObject.lookup anyway. Not clear that Node.lookup needs to be consulted, either - wouldn't
you just look in the TopComponent.lookup? Or more generally, in a Component implementing Lookup.Provider? Be precise
about exactly where PrintProvider is looked for. If you have suggestions about convenient places to register a PP where
they will be found, they should be marked nonnormative.

As to [JG01] and [JG05]: the keys (print.name, print.size etc.) should be defined as constants in print api
(PrintManager), am I right?

Yes, constants in PrintManager would make sense. Then you can put the detailed description of the meaning of each
constant in its Javadoc.

Question about key in putClientProperty: can *string* key (the name of class) java.awt.Printable.class.getName() be 
used in a print client?

The atvantage of this use case is that a client should not have dependency to print module. Now a data of many modules 
(UML, mobility, GUI Builder etc.) can be printable but the modules don't depend on the print module. I'd not like to 
use in print clients hard-coded constans (such as "print.size" etc.)

About key java.awt.Printable.class: not-null value indicates that a component is printable and will be in Print Preview 
(null value means that the component is not printable). The value (if it is non empty string) is name shown in 
header/footer. If value is not string or empty string, the name is taken from the TC. So, one key with two meanings.

Should I separate the key into two keys: "is component printable" and "the name of component"? Or current 
implementation is acceptable?

"java.awt.Printable" is nearly as misleading as Printable.class. Prefer a straightforward and descriptive constant such
as "print.header".

Clients are not forced to actually import PrintManager to use a simple constant. They can just copy the string directly
into their sources. The Javadoc will display the value of any String constant.

I would recommend using two keys, e.g. "printable" = true (Boolean.TRUE that is, _not_ "true") and optional
"print.header" = "...". I think this is clearer than having "" be a magic value. Alternately, "print.header.automatic" =
true could be used to mark a printable component whose header should be calculated automatically from TC.displayName. As
before, I am not convinced that such an automatic display name feature is really necessary to begin with - are there
some use cases where it would be unreasonable for the client to explicitly set a printable header?

To JG09: looks like you removed getDefault() but then made the constructor (implicitly) public! You need

private PrintManager() {}

Re: [JG01] The keys has been define as String constants in PrintManager:

PRINT_NAME = "print.name"
PRINT_WEIGHT = "print.weight"
PRINT_PRINTABLE = "print.printable"

"print.printable" indicates whether the component is printable
"print.name" means the name of component which is displayed in footer/header (the left part of header by default)
"print.weight" is used to set order if several components are printed, the components are shown from the left to right

Re: [JG02] The name of component is set via string "print.name" property.

Re: [JG03] It is up to developer which component will be printable. It may be inner component or TC or something else.
If have, for example, a diagram which is placed into scroll bar and scroll bar lives in TC, you should set
"print.printable" property in a diagram, not TC (I think that you would not print scroll bar).

Re: [JG04] Done: the paragraph is included into <p class="nonnormative">.

Re: [JG05] Dimension/size is not used anymore. Javadoc has been updated.

Re: [JG06] Done: {@link ...} is used.

Re: [JG07] Javadoc of PrintProvider class has been improved.

Re: [JG08] Javadoc of PrintProvider class has been updated.

Re: [JG09] Method PrintManager.getDefault() has been removed, method getPrintPreviewAction() has been renamed to
printPreviewAction() and is static. Private constructor PrintManager() has been added.

Re: [JG10] Updated: TopComponent is used only, "data object" and "node" have been removed.

Created attachment 63079 [details]
Updated javadoc

PS: The question is what shall I do with the coverage.zip!? I was hoping it will be an HTML page.

Y04, additional comment: Friend API stability is not enough, platform does not export any friend java APIs outside of 
its cluster. No reason to start now. I would like you to declare the API as "Stable".

When I run "ant coverage" under print/test folder, I get the result with one file only:
  print/test/coverage/metadata.emma
I don't have any idea how to view it.

Re: [Y04] Print API has stable interfaces which are in final state. I've changed the category to "stable" in file
arch.xml, id="arch-overall".

Should I change friend declaration

<friend-packages>
    <friend>...</friend>
    <friend>...</friend>
    <package>org.netbeans.modules.print.api</package>
    <package>org.netbeans.modules.print.spi</package>
</friend-packages>

to public

<public-packages>
    <package>org.netbeans.modules.print.api</package>
    <package>org.netbeans.modules.print.spi</package>
</public-packages>

declaration in project.xml?

Yes, turn the friend packages to public ones.

Updated: turned print api/spi packages from friend to public.

Looking much better, thanks!


[JG11] Is there anything more to say about the semantics of printPreviewAction? The example mentions that it can just be
added to a JToolBar. There is no mention of how it is connected to the printable component, i.e. how it decides what to
preview. Currently active TopComponent, if it is PRINT_PRINTABLE? Last focused JComponent or its nearest ancestor marked
PRINT_PRINTABLE? Nearest JComponent ancestor marked PRINT_PRINTABLE of the toolbar presenter (and if so, what happens if
the action is not presented in a toolbar)? Magic? (This goes back to JG03.)

If there is a global Print Preview action in the File menu (or KB shortcut), how does it know what you are printing?
Javadoc for PrintManager says "selected nodes or opened views" but this is vague. Selected nodes of what? How do nodes
correspond to JComponent's? What are "opened views"? Be precise, and use @link (or @linkplain) to point directly to
other relevant NB (or Java) APIs.

Re: [JG11] I've added details:

   * How does Print Manager decide what to preview?<p>
   *
   * At first, the manager searches {@linkplain org.netbeans.modules.print.spi.PrintProvider}
   * in the lookup of the active top component {@link org.openide.windows.TopComponent}.
   * If a print provider is found, it is used by the print manager for preview.
   * Otherwise, it tries to obtain printable components (marked as {@linkplain #PRINT_PRINTABLE})
   * among the descendants of the active top component. All found printable components
   * are passed into the Print Preview dialog.<p>
   * 
   * If there are no printable components, printable data are retrieved from the selected
   * nodes {@link org.openide.nodes.Node} of the active top component: the manager
   * searches {@linkplain org.netbeans.modules.print.spi.PrintProvider} in the lookups
   * of the nodes. All pages {@linkplain org.netbeans.modules.print.spi.PrintPage},
   * taken from found providers, are displayed in the preview.<p>
   * 
   * If nodes don't have print providers in lookups, the manager gets the cookie
   * {@link org.openide.cookies.EditorCookie} from the {@link org.openide.loaders.DataObject}
   * of the nodes. The {@linkplain javax.swing.text.StyledDocument} documents, returned by
   * the editor cookies, contain printing information (text, font, color). This information
   * is shown in the print preview. So, any textual documents (java sources, html, xml, plain
   * text etc.) are printable by default.

Created attachment 63340 [details]
Updated javadoc

To JG11: well, I would never have guessed all that! But I don't think it all makes sense. First of all, if you are
already looking in TC.lookup for PrintProvider, why would you also look in TC.activatedNodes.lookup for the same thing?
It doesn't make much sense - TC.lookup in most cases just delegates to TC.activatedNodes.lookup anyway. Second, why
would you look for a DataObject among the nodes just to get an EditorCookie, when you could just look for EditorCookie
in the nodes directly - or, better, in the TC directly? Would suggest a simpler 3-step search:

1. TC.Registry.activatedTC.lookup(PP) (~ Utilities.actionsGlobalContext().lookup(PP))
2. TC.Registry.activatedTC.components recursively
3. TC.Registry.activatedTC.lookup(EditorCookie) (~ Utilities.actionsGlobalContext().lookup(EC))

This still seems strange because you specifically recommend placing Print Preview as a toolbar button inside a
TopComponent, yet there is no real linkage to that TC from the action: you rely on the hope that the TC will be
considered active by the window system at the time the Preview button is clicked, which is not guaranteed in all window
managers. (Timing of focus should be considered unreliable.) Generally speaking, for actions which might be installed in
a specific place (not a global toolbar or menu item or KB shortcut), we require that they implement ContextAwareAction,
and that the code presenting the action create a context-specific instance which does not pay any attention to the
global selection, e.g.:

myJToolBar.add(PrintManager.printPreviewAction().createContextAwareInstance(Lookups.singleton(myTopComponent)));

In this case, your search algorithm is so baroque that I would recommend killing it altogether for the action actually
returned from PM.pPA(). (You can still use some similar algorithm for a separate action which appears in the File menu
and so on.) In that case, printPreviewAction() could have overloads or variants specifying what should be printed, e.g.

/** no need for them to be marked PRINT_PRINTABLE in this case: */
printPreviewAction(Component... printableComponents)
printPreviewAction(PrintProvider... customPrintProviders)
printPreviewAction(StyledDocument... documents)


BTW you should learn how to use @link and @linkplain properly. Use {@link SomeClass} when you want "<a
href=".../SomeClass.html><code>SomeClass</code></a>" to appear in output. Use {@linkplain SomeClass something} when you
want "<a href=".../SomeClass.html>something</a>" to appear in output. As with any hypertext, make sure the text reads
naturally as English, with links available to clarify meaning where required. For example, to fix up your current Javadoc:

diff --git a/print/src/org/netbeans/modules/print/api/PrintManager.java
b/print/src/org/netbeans/modules/print/api/PrintManager.java
--- a/print/src/org/netbeans/modules/print/api/PrintManager.java
+++ b/print/src/org/netbeans/modules/print/api/PrintManager.java
@@ -40,7 +40,15 @@
  */
 package org.netbeans.modules.print.api;
 
+import java.awt.Container;
 import javax.swing.Action;
+import javax.swing.text.StyledDocument;
+import org.netbeans.modules.print.spi.PrintPage;
+import org.netbeans.modules.print.spi.PrintProvider;
+import org.openide.cookies.EditorCookie;
+import org.openide.loaders.DataObject;
+import org.openide.nodes.Node;
+import org.openide.windows.TopComponent;
 
 /**
  * <p class="nonnormative">
@@ -135,22 +143,22 @@
    *
    * How does Print Manager decide what to preview?<p>
    *
-   * At first, the manager searches {@linkplain org.netbeans.modules.print.spi.PrintProvider}
-   * in the lookup of the active top component {@link org.openide.windows.TopComponent}.
+   * At first, the manager searches for {@link PrintProvider}
+   * in the {@linkplain TopComponent#getLookup lookup} of the {@linkplain TopComponent.Registry#getActivated active top
component}.
    * If a print provider is found, it is used by the print manager for preview.
-   * Otherwise, it tries to obtain printable components (marked as {@linkplain #PRINT_PRINTABLE})
-   * among the descendants of the active top component. All found printable components
+   * Otherwise, it tries to obtain {@linkplain #PRINT_PRINTABLE printable} components
+   * among the {@linkplain Container#getComponents descendants} of the active top component. All found printable components
    * are passed into the Print Preview dialog.<p>
    * 
-   * If there are no printable components, printable data are retrieved from the selected
-   * nodes {@link org.openide.nodes.Node} of the active top component: the manager
-   * searches {@linkplain org.netbeans.modules.print.spi.PrintProvider} in the lookups
-   * of the nodes. All pages {@linkplain org.netbeans.modules.print.spi.PrintPage},
+   * If there are no printable components, printable data are retrieved from the
+   * {@linkplain TopComponent#getActivatedNodes selected nodes} of the active top component: the manager
+   * searches for {@link PrintProvider} in the {@linkplain Node#getLookup lookups}
+   * of the nodes. All {@link PrintPage}s
    * taken from found providers, are displayed in the preview.<p>
    * 
-   * If nodes don't have print providers in lookups, the manager gets the cookie
-   * {@link org.openide.cookies.EditorCookie} from the {@link org.openide.loaders.DataObject}
-   * of the nodes. The {@linkplain javax.swing.text.StyledDocument} documents, returned by
+   * If nodes don't have print providers in lookups, the manager gets
+   * {@link EditorCookie} from the {@link DataObject}
+   * of the nodes. The {@link StyledDocument}s returned by
    * the editor cookies, contain printing information (text, font, color). This information
    * is shown in the print preview. So, any textual documents (java sources, html, xml, plain
    * text etc.) are printable by default.

Thank you very much for suggestion how to improve print preview action and javadoc!

I agree that search mechanism can be easier and don't use DataObject for PrintProvider.
Also I think that EditorCookie can be taken from selected nodes instead of TC:
if user selects a node (for example, java class) in project
view but doesn't open it in the Editor (there is no TC for java source,
but node can provide EditorCookie). So, search will be:

1. TC.Registry.activatedTC.lookup(PP)
2. TC.Registry.activatedTC.components recursively
3. TC.Registry.activatedTC.activatedNodes().lookup(EditorCookie)

Do you agree?

Toolbar: I'll modify the PrintPreview action to be context aware.
As the input parameter of the action is top component, I see simpler implementation:

class PrintManager {
  public static Action printPreviewAction(TC topComponent)
}
and developer can put in own code:

myToolBar.add(PrintManager.printPreviewAction(myTopComponent));

not too complex and elegant, do you agree?

I'd not like to have three methods

printPreviewAction(Component... printableComponents)
printPreviewAction(PrintProvider... customPrintProviders)
printPreviewAction(StyledDocument... documents)

because it applies restriction to API: what if in future text can be obtain not from StyledDocument
or paintable data can be taken in another way? The method printPreviewAction(TC topComponent) covers
all of them because TC contains a data being printed and it is up to implementation how to retrieve it.

I've noted following comment "because it applies restriction to API": I do not think there is any restriction by 
directly specifying the type of the methods. In case you decide to release new version of the API and add support for 
new interface, you can always add new static method that will consume it. This has two advantages over TopComponent 
method: 1. people can see the possible arguments from the javadoc; 2. you do not expose TopComponent from the 
signatures at all, making your API more self contained.

Additional comments about printPreviewAction method:

Just now all use cases in the NetBeans modules (UML, GUI Builder, Mobility, Image viewer etc. (complete list see on
print.netbeans.org)) are just marking components with "print.printable" key. Some of the custom views (top components)
have PrintPreview action on the toolbar and code looks like:

class CustomTopComponent extends TopComponent {
  ...
  toolBar.add(PrintManager.printPreviewAction());
  // or with new signature
  toolBar.add(PrintManager.printPreviewAction(this));
}

class CustomComponent extends javax.swing.JComponent {
  ...
  putClientProperty("print.printable", Boolean.TRUE); // NOI18N
}
very easy and not complex.

Just now no modules use PrintProvider or StyledDocument. If there is any textual information in the editor, it will be
printable automatically. This feature is provided by print module. So, developer should take care of JComponent content
or create PrintProvide for own, may be complex, data. In the last case, the code will be still easy:

class CustomTopComponent extends TopComponent {

  public Lookup getLookup() {
    return Lookups.singleton(myPrintProvider);
  }
  ...
  toolBar.add(PrintManager.printPreviewAction());
  // or with new signature
  toolBar.add(PrintManager.printPreviewAction(this));
  ..
}
This code is clear to read, understand and maintain.

What if we have printPreviewAction(JComponent [] components) method only instead of pPA(TC tc)?
Two missing parameters should be added: name and lastModifiedTime (name and time are shown in the header/footer)
As usual the context of TC is complex: jscroll bar, inner panels and so on. Developer has to have reference to
the inner printable components in the custom TC: extra private attributes for printing only is not good shape.

Okey, it can be done, not too hard to implement. But, imagine what if the list of the printable components is
created dynamically? If we just mark "print.printable" a component to be printable, each component can set/reset
the key by own rules and the custom TC has not to know about its inner printable components. TC is used as a root
to find components being printed and to obtain name and time only. Also it is very easy for developer to put only *one*
and obvious argument - TC - in print preview action instead of creating the list of the components. It was me who
added "printing" code in all custom NB modules (see the list on http://print.netbeans.org), I familiar with
that difficulties which can appear if the API is not convinient for using.

One moment: we can not reject the marking a component by key. The reason is that TC can have no print preview action
on the toolbar at all, but the content may be printable.

So, I'm voting to have method

printPreviewAction(TopComponent tc);

If it will be nicer, we can have also extra two method:

printPreviewAction(PrintProvider [] providers);
printPreviewAction(JComponent [] component, String name, Date lastModifiedTime);

Any ideas?

I cannot help myself, but my natural reaction to "Just now no modules use PrintProvider or StyledDocument." has to be, 
can PrintProvider be removed from the API until it is needed? It can always be added compatibly later, can't it?

Otherwise I do not understand what is so special about TopComponent? For me printPreviewAction(TopComponent tc) is 
just like printPreviewAction(JComponent tc) or printPreviewAction(Lookup context). But I may be missing something...

Yes, of course, PrintProvider can be removed from SPI, but as I wrote "Just *now* no modules use PrintProvider...". It
there are a plans to use print provider for BPEL and XSLT mapper. Draft of code is written and it is not convenient to
remove it and add back 

Jesse suggested adding extra methods:

printPreviewAction(PrintProvider...)
printPreviewAction(JComponent...)

I agree with him, but I'd like to keep also

printPreviewAction(TC..)

So, I'm waiting the final approval to implement three methods in PrintManager

printPreviewAction(PrintProvider...)
printPreviewAction(JComponent...)
printPreviewAction(TC..)

P.S.

Will be on vacation till July 13, 2008 here:
http://maps.google.com/maps/mm?ie=UTF8&hl=en&ll=60.173538,29.461212&spn=0.031932,0.074501&z=14

Why you need printPreviewAction(TC..) when you have printPreviewAction(JComponent)? Do you know that TopComponent is 
subclass of JComponent?

Sounds reasonable... agree.

The list of the methods in PrintManager to be approved is:

printPreviewAction(PrintProvider...)
printPreviewAction(JComponent...)

I think that these methods are enough.

Created attachment 64709 [details]
Updated javadoc

What is the intention with the product of this review? Still anything for 6.5?
(we are several days after feature-freeze now)

yes, print/preview was planned for NetBeans 6.5.
if it is too late, let it be for next release.

I believe that the process is about finishing.
UML team is waiting printing in NB 6.5

I've made suggested changes:

1. Added two new methods to PrintManager
     printAction(JComponent component)
     printAction(PrintProvider [] providers)

2. Method printPreviewAction() has been removed.

3. Search algorithm for File | Print action became easier:
   - looks printable components of the active top component
   - otherwise, gets EditorCookie of selected nodes for printing textual information

4. Javadoc has been updated.

Any comments?

[JG12] PRINT_WEIGHT sounds like its values should be "bold, normal, light" (i.e. http://en.wiktionary.org/wiki/boldness)
- do you perhaps mean "order" or "priority" or something like that? Minor issue, just a possible point of confusion to
new API users.


[JG13] Still do not know why DataObject is involved in looking for EditorCookie when you can find this cookie directly
in Node.getLookup().


[JG14] Why the change from "printPreviewAction" to "printAction"? I assume that you can in fact print right from the
Print Preview dialog, but I think it is conventional for a toolbar button labeled "Print" to immediately print, so if
this action instead opens a preview dialog I think that should be emphasized.

Re: [JG12] PRINT_WEIGHT means order in which components should be shown.
Agree, I'll rename it to PRINT_ORDER.

Re: [JG13] Ok, will obtain EditorCookie from Node.getLookup() directly.

Re: [JG14] There was an issue http://www.netbeans.org/issues/show_bug.cgi?id=139442 - "File > Print" isn't in IDE,
and jrojcek suggested having one action "Print". I don't see any problem if action "Print" opens Preview dialog.
User can press "Print" button on it and it sends data to the printer.

Items 12 and 13 will be fixed tomorrow.

JG14 - OK, just making sure it is intentional.


Otherwise API looks OK to me now. Anyone else commenting on it - Yarda?

> UML team is waiting printing in NB 6.5

Where will the API+UI land? Which cluster? I did not see any discussion about that here yet.

As it was discussed by e-mail, print module will live in ide9 cluster and be a part of the NetBeans core.

Integrated into 'main-golden', available in NB_Trunk_Production #324 build
Changeset: http://hg.netbeans.org/main/rev/2fce965931c7
User: Vladimir Yaroslavskiy <yaroslavskiy@netbeans.org>
Log: [Issue #136903] API for print preview functionality: fix actions

Items [JG12] PRINT_WEIGHT -> PRINT_ORDER and
[JG13] obtain EditorCookie from Node.getLookup() directly - have been fixed in main.

Should print API be repackaged from
org.netbeans.modules.print.api/spi to
org.netbeans.api/spi.print ?

Do you have any comments?

JavaFX team is waiting Print/Preview functionality too... (information from Alexandr Scherbatiy aka sunflower)

See issue 140745 JavaFX Script Print preview functionality

Reviewers, do you have comments/suggestions?

And what about question:

Should print API be repackaged from
org.netbeans.modules.print.api/spi to
org.netbeans.api/spi.print ?

Thanks,

If you intend to maintain this compatibly in the future and export public packages then I think
org.netbeans.api/spi.print is appropriate. If you are unsure about the future and will stick with friend dependencies
only, then better to leave as org.netbeans.modules.print.api/spi for now.

Print api is stable and not too complex. I think that it can be easy maintained in the future. If there is no 
objections, I will do repackaging.

Repackaging o.n.m.print.api/spi -> o.n.api/spi.print has been done.

If there are no objections, print module can be a part of the NetBeans 6.5 core and moved to ide9 cluster. Am I right?

> can be a part of the NetBeans 6.5 core

Not sure what you exactly mean by this. If you want any commitment from Core team with regard to 6.5 and print API, you
need to talk to me.

> and moved to ide9 cluster

I don't have a problem with this.

I meant that Print module would be in Base IDE, see matrix on the page
http://bits.nbextras.org/netbeans/trunk/nightly/latest

Now the Print module lives in xml2 cluster and available in "Web & Java EE" and "All" versions of the NetBeans only.
If the Print module is in ide9 cluster, it will be in Base IDE and available in all versions.

Do you right person for this question? Who should approve moving of the Print module from xml2 to ide9? I guess that
"moving" is just moving one line "print,\" from "xml" to "ide" cluster section in nbbuild/cluster.properties, right?

> If the Print module is in ide9 cluster, it will be in Base IDE and available in all versions.
> Who should approve moving of the Print module from xml2 to ide9?

You should have an agreement from HIE and QE. Also a positive result of this api review is another prerequisite.

QE: Print module has being tested by Victoria Zhukovskaya (Victoria.Zhukovskaya@Sun.COM aka victoriaz). I hope she can
give the status of the module.

HIE: the module was designed by former HIE engineer Jiri Kopsa. There were a lot of meeting with him devoted to the
print mockup. Specification was published on the http://print.netbeans.org/docs.html. Should anyone from HIE team to
review the specification?

Victoria is on vacation now and will response on July 29 (or may be July 25).
From my point, the module is in good shape: all bugs have been resolved, all planned features
were implemented, dashboard is empty.

Recently, the print module was tested by joshis (adding to cc). Can you add something?

I've been asked to provide UI review. It is available at http://ui.netbeans.org/docs/ui/print_dialog_UI_review/ 

Summary: 
--------
After fixing the review findings, the dialog will be suitable as part of base IDE. 

Other than the findings, I do see some issues with general flow (mainly in print options dialog) but these are not total
flow-stoppers and their solution would be more time-consuming and certainly out-of-scope for the following release. From
UX point of view, these do not have to be addressed for 6.5 but we should keep them in mind and probably address them in
later releases (for brief description of these problems see the link above).

I've tested Printing Preview functionality with NetBeans IDE Dev (Build 200807240010) and BPEL Editor. No serious issues
found.

OK from HIE's perspective. 

HIE and QE approved Print module. If there are no any objections/comments, I'll move printing to the ide10 cluster.

Hi yaroslavskiy! Sorry for the late reply. I have currently no objections to the new print preview except for the ones I
already submitted to you (and that are already fixed). I was personally pleasantly surprised when I saw the print
preview for the first time, so I would say "GO" ;)...

Useful documents

Architecture Review Steps: http://openide.netbeans.org/tutorial/review-steps.html
API Development: http://openide.netbeans.org/tutorial/api.html

The print module has been moved from xml2 to ide10 cluster in NetBeans 6.5.
changeset: http://hg.netbeans.org/main/rev/46db2c3c8095

Integrated into 'main-golden', available in build *200807301401* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/46db2c3c8095
User: Vladimir Yaroslavskiy <yaroslavskiy@netbeans.org>
Log: [Issue #136903] API for print preview functionality: move from xml2 to ide10 cluster