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.aditoweb.nbm.designerbase.*</publicPackage> </publicPackages> <moduleDependencies> <dependency>
<id>org.netbeans.modules:org-netbeans-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-netbeans-modules-versioning-util</id> <type>impl</type> <explicitValue>org.netbeans.modules.versioning.util = 201609300101</explicitValue> </dependency> <dependency> <id>org.netbeans.api:org-netbeans-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]
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