Bug 228409

Created attachment 133420 [details]
apisupport ant patch

Created attachment 133421 [details]
java api patch

Added patches for Apisupport and for Java API

TZ01: The api.java is not project aware it should not contain any project related API. You want to use java.project or java.api.common depending on the stability of the proposed API.

TZ02: The api.java should not contain any UI.

TZ03: The name of the interface is probably not very good as it has not much in common with its purpose. The ProjectModifierImplementation is very general.

TZ04: The getPackagesToExport seems as leakage of implementation and is probably non needed in the SPI or can be merged with isExportSelectedPackages.

TZ05: Passing null to FileOwnerQuery  in ExportPackageAction.createContextAwareInstance

TZ06: Unsafe cast in ExportPackageAction.createContextAwareInstance

TZ07: Unit test

(In reply to comment #4)
> TZ01: The api.java is not project aware it should not contain any project
> related API. You want to use java.project or java.api.common depending on the
> stability of the proposed API.
> 
> TZ02: The api.java should not contain any UI.

TZ01-02 Ok, I've suggested it to mkozeny, given that AccessibilityQuery is in the same module and that it's current clients have api.java as common denominator. But moving it elsewhere (both API and the UI is probably ok)

> 
> TZ03: The name of the interface is probably not very good as it has not much in
> common with its purpose. The ProjectModifierImplementation is very general.
> 

+1
my suggestion is to include Export, Public, Package, Accessibility, Modifier, Handler words maybe or their combination. 


MK1: apichanges entry should not include notes on implementation, just the contract

MK2: implementation wise - Project project = FileOwnerQuery.getOwner(selectedPackages.iterator().hasNext()?selectedPackages.iterator().next():null);
is not a good pattern IMHO, we should either guard against selecting packages from multiple projects or deal with multiple implementation instances simultaneously

MK3 (for optional consideration). The word "export" is likely associated with OSGI, in netbeans module system it's not as widely used, maybe the API shoudl include the label for the action. No strong opinion though.

Created attachment 133539 [details]
Updated patch according to tzezula comments

Added patch according to tzezula's T01 - T06 and mklient's comments.

appears ok to me now.

minor comment about getAllPackages() method. That one can be IO intensive (therefore slow) on big projects, if it ends up being so, we would have to abandon the check, deprecate the method and assume that whatever the user selected is actually a package.

https://hg.netbeans.org/core-main/rev/1b086a96dae6

Integrated into 'main-golden', will be available in build *201304272301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/1b086a96dae6
User: Martin Kozeny <mkozeny@netbeans.org>
Log: #228409: "Export Package" function is now provided as an API. Now is possible to implement interface PackageModifierImplementation for particular project.

https://hg.netbeans.org/core-main/rev/53b7b150f138

maven implementation along with a simplification of the API. please review

I've filed a separate issue 229440 for osgi bundles, the possibilities of writing Export-package and Private-Package are endless making automated editing harder.