Put together a proposal on the Apache NetBeans Wiki and we can discuss it. Discussion in this thread is indeed going to stop very soon unless an actual concrete proposal is put together.
Gj On Friday, July 13, 2018, Peter Nabbefeld <[email protected]> wrote: > > Yes, I know. I just wanted to make sure discussion doesn't stop at this > point. In the past, I'd already some discussions of this type, mostly > ending some time later anywhere else. > > So, while Johannes was *really* helpful, I just want to keep the direction > of the topic, as I see the move to Apache as a chance, to finally implement > a better API release process. This chance will probably never come back. > > Kind regards > > Peter > > > > Am 13.07.2018 um 12:03 schrieb Geertjan Wielenga: > >> Yes, of course. But Johannes was responding to this statement of yours and >> trying to help you and show you how to do this: >> >> - Alternatively You could depend on the implementation version; but I >> don't >> >>> see how to do that, if You're using Maven. >>> >> >> Gj >> >> On Fri, Jul 13, 2018 at 12:01 PM, Peter Nabbefeld <[email protected] >> > >> wrote: >> >> Hi Johannes, >>> >>> thank You for the info! I'll have to find out what I was missing then. >>> Nevertheless, IMHO a module depending on an implementation is not very >>> convenient, as it will always fail to load when the dependency changed in >>> any way, not necessarily the API (in that case the spec version should >>> probably change, too). >>> >>> Kind regards >>> Peter >>> >>> >>> >>> Am 13.07.2018 um 10:33 schrieb Johannes Boesl: >>> >>> Hi there, >>>> >>>> just for completeness. It's well possible to depend on implementation >>>> version using maven. Here is an abstract from one of my poms: >>>> >>>> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> >>>> <artifactId>nbm-maven-plugin</artifactId> <configuration> >>>> <publicPackages> <publicPackage>de.adito.aditow >>>> eb.nbm.designerbase.*</publicPackage> </publicPackages> >>>> <moduleDependencies> <dependency> <id>org.netbeans.modules:org-n >>>> etbeans-modules-projectui</id> >>>> <type>impl</type> <explicitValue>org.netbeans.modules.projectui = >>>> 201609300101</explicitValue> </dependency> <dependency> >>>> <id>org.netbeans.modules:org-netbeans-modules-git</id> >>>> <type>impl</type> >>>> <explicitValue>org.netbeans.modules.git = 201609300101</explicitValue> >>>> </dependency> <dependency> <id>org.netbeans.modules:org-n >>>> etbeans-modules-versioning-util</id> <type>impl</type> <explicitValue> >>>> org.netbeans.modules.versioning.util = 201609300101</explicitValue> >>>> </dependency> <dependency> <id>org.netbeans.api:org-netbe >>>> ans-modules-csl-api</id> >>>> <type>impl</type> <explicitValue>org.netbeans.modules.csl.api/2 = >>>> 2</explicitValue> </dependency> </moduleDependencies> >>>> <moduleType>eager</moduleType> </configuration> </plugin> </plugins> >>>> </build> >>>> >>>> With kind regards, >>>> Johannes Boesl >>>> >>>> >>>> Am 13.07.2018 um 01:11 schrieb Peter Nabbefeld: >>>> >>>> Hello all, >>>>> >>>>> I personally don't like "Friend" APIs, as really I like the idea of an >>>>> open, extensible IDE. >>>>> >>>>> From my point of view, Friend APIs make it difficult or impossible to >>>>> extend NetBeans for personal use: >>>>> - You have to ask for being added to the friends list. This is >>>>> especially a problem, if You want to implement some private-use >>>>> feature, e.g. for Your employer. >>>>> - Alternatively You could depend on the implementation version; but I >>>>> don't see how to do that, if You're using Maven. >>>>> - Third possibility is just patching the modules to remove the friends >>>>> and make the API public - very ugly, and You have to do it after every >>>>> update. >>>>> >>>>> OTOH, having a friends-only API leads to fewer dependencies on the >>>>> API, thus less impact from changes to the API, which makes work easier >>>>> for the developers, of course. >>>>> >>>>> However, if an API isn't stable, yet, it could also just be flagged as >>>>> "Under Development", thus telling users of those, that it is subject >>>>> to change. Also, as it is possible to use default methods in >>>>> interfaces from Java 8, it should be less of a problem to extend an >>>>> existing API. But You can use the API on Your own risk without any >>>>> conflicts. >>>>> >>>>> An exception of course is having APIs only for modularity, if classes >>>>> are spread over different modules and need an API to interact with >>>>> each other. In this case the API's purpose is not to integrate >>>>> extensions, but to split responsibilities - in this case I fully agree >>>>> these are not for public use. >>>>> >>>>> I'd be interested in comments on this - so, what do You think? >>>>> >>>>> Kind regards >>>>> >>>>> Peter >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected]. >>>>> apache.org >>>>> >>>>> For further information about the NetBeans mailing lists, visit: >>>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> For further information about the NetBeans mailing lists, visit: >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >>> >>> >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
