Bug 228409 - export package as spi
export package as spi
Status: RESOLVED FIXED
Product: apisupport
Classification: Unclassified
Component: Project
7.4
PC Windows 7
: P3 (vote)
: 7.4
Assigned To: Martin Kozeny
issues@apisupport
: API, API_REVIEW_FAST
Depends on: 200833
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-09 13:32 UTC by Milos Kleint
Modified: 2013-05-07 08:38 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
apisupport ant patch (16.59 KB, patch)
2013-04-10 14:22 UTC, Martin Kozeny
Details | Diff
java api patch (13.01 KB, patch)
2013-04-10 14:22 UTC, Martin Kozeny
Details | Diff
Updated patch according to tzezula comments (29.02 KB, patch)
2013-04-17 11:43 UTC, Martin Kozeny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Milos Kleint 2013-04-09 13:32:08 UTC
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
Comment 1 Martin Kozeny 2013-04-10 14:22:08 UTC
Created attachment 133420 [details]
apisupport ant patch
Comment 2 Martin Kozeny 2013-04-10 14:22:24 UTC
Created attachment 133421 [details]
java api patch
Comment 3 Martin Kozeny 2013-04-10 14:29:20 UTC
Added patches for Apisupport and for Java API
Comment 4 Tomas Zezula 2013-04-10 19:01:04 UTC
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
Comment 5 Milos Kleint 2013-04-11 06:30:28 UTC
(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.
Comment 6 Martin Kozeny 2013-04-17 11:43:37 UTC
Created attachment 133539 [details]
Updated patch according to tzezula comments
Comment 7 Martin Kozeny 2013-04-17 11:44:51 UTC
Added patch according to tzezula's T01 - T06 and mklient's comments.
Comment 8 Milos Kleint 2013-04-18 09:20:41 UTC
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.
Comment 9 Martin Kozeny 2013-04-24 13:00:48 UTC
https://hg.netbeans.org/core-main/rev/1b086a96dae6
Comment 10 Quality Engineering 2013-04-28 02:18:51 UTC
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.
Comment 11 Milos Kleint 2013-05-07 08:38:14 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo