as a follow up to issue 200833, please provide APIs to allow maven nbm projects and osgi projects (and maybe more) to implement export package behaviour
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.
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.
Integrated into 'main-golden', will be available in build *201304272301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Martin Kozeny <firstname.lastname@example.org>
Log: #228409: "Export Package" function is now provided as an API. Now is possible to implement interface PackageModifierImplementation for particular project.
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.