Need guidance/comments on package (re-)naming

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Need guidance/comments on package (re-)naming

15 knots
Hi all,

my plugin has an API for consumers of the plugin as well as an API for the extension point the plugin provides.
The consumer API has 5 public classes and interfaces in a single package whereas the extension point API has 16 public classes and interfaces in 2 packages.

I want to keep these APIs separated.
Since the package of the consumer API currently is a complete misnomer, I have to rename it.

So my question is: Are the any conventions in CDT on naming the packages? Or could anybody help me to find good package names?

The top level package (and name) of my plugin is
org.eclipse.cdt.cmake.is.core.
Below that are
- the misnamed *.language.settings.providers package which contains the consumer API and.
- the extension point API is in the top-level package (not sure whether that is a good idea) and in the sub-package *.builtins.

What do you think of having the consumer APi in the top-level package (o.e.c.cmake.is.core) and having the 2 extension point API package to a package below o.e.c.cmake.is.core? For example o.e.c.cmake.is.core.ep and o.e.c.cmake.is.core.ep.builtins?

Please comment.

Martin


_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Need guidance/comments on package (re-)naming

Alexander Fedorov
Hi Martin,

I don't think the "ep" is the right segment for API, because "extension point" is just a technology to contribute more implementations. You may decide to support contribution via OSGi components later - but the interface will be the same, right? So, I think the extraction of "extension point API" is not a descriptive point of view.

Regards,
AF

22.05.2020 20:06, 15 knots пишет:
Hi all,

my plugin has an API for consumers of the plugin as well as an API for the extension point the plugin provides.
The consumer API has 5 public classes and interfaces in a single package whereas the extension point API has 16 public classes and interfaces in 2 packages.

I want to keep these APIs separated.
Since the package of the consumer API currently is a complete misnomer, I have to rename it.

So my question is: Are the any conventions in CDT on naming the packages? Or could anybody help me to find good package names?

The top level package (and name) of my plugin is
org.eclipse.cdt.cmake.is.core.
Below that are
- the misnamed *.language.settings.providers package which contains the consumer API and.
- the extension point API is in the top-level package (not sure whether that is a good idea) and in the sub-package *.builtins.

What do you think of having the consumer APi in the top-level package (o.e.c.cmake.is.core) and having the 2 extension point API package to a package below o.e.c.cmake.is.core? For example o.e.c.cmake.is.core.ep and o.e.c.cmake.is.core.ep.builtins?

Please comment.

Martin


_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Need guidance/comments on package (re-)naming

15 knots
Hi Alexander,

Am Fr., 22. Mai 2020 um 21:10 Uhr schrieb Alexander Fedorov <[hidden email]>:
Hi Martin,

I don't think the "ep" is the right segment for API, because "extension point" is just a technology
Good point.
But with 5 public classes for the consumer API vs. 16 classes for the contribute more implementations API I still want to keep them separated to not confuse people that implement a consumer.
That contribute more implementations API actually is for third-party compiler vendors so they can provide a plugin that understands the compiler specific command-line options and passes these to the indexer through the cmake indexer support plugin. That plugin would then participate in command-line analysis.
The main benefit to introduce that API was to reduce the number of incoming enhancement requests.

WDYT, would participant give a good name for the contribute more implementations API?
Or thirdparty?

Martin

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Need guidance/comments on package (re-)naming

Jonah Graham
Hi Martin,

I think it is great you are trying to separate it. To answer your original first question, no there are no conventions in CDT that I know of. Historically all the code is in one (or a few) big bundle and separated somewhat into internal and non-internal packages. This is true of JDT and Eclipse Platform too where we inherit a lot of CDT original design from. The current code is more split by feature than by programmers purpose.

participant is a good name for something that participates in the operation via extension point, e.g. some classes in Eclipse Platform (like IDocumentSetupParticipant) use that as part of their name. javadoc starts like this for IDocumentSetupParticipant

 * Participates in the setup of a text file buffer document.
 * <p>
 * This interface is the expected interface for extensions provided for the
 * <code>"org.eclipse.core.filebuffers.documentSetup"</code> extension point.


HTH,
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Mon, 25 May 2020 at 16:11, 15 knots <[hidden email]> wrote:
Hi Alexander,

Am Fr., 22. Mai 2020 um 21:10 Uhr schrieb Alexander Fedorov <[hidden email]>:
Hi Martin,

I don't think the "ep" is the right segment for API, because "extension point" is just a technology
Good point.
But with 5 public classes for the consumer API vs. 16 classes for the contribute more implementations API I still want to keep them separated to not confuse people that implement a consumer.
That contribute more implementations API actually is for third-party compiler vendors so they can provide a plugin that understands the compiler specific command-line options and passes these to the indexer through the cmake indexer support plugin. That plugin would then participate in command-line analysis.
The main benefit to introduce that API was to reduce the number of incoming enhancement requests.

WDYT, would participant give a good name for the contribute more implementations API?
Or thirdparty?

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: Need guidance/comments on package (re-)naming

15 knots
Hi Jonah,

Am Mo., 25. Mai 2020 um 23:42 Uhr schrieb Jonah Graham <[hidden email]>:
participant is a good name for something that participates in the operation via extension point, e.g. some classes in Eclipse Platform (like
IDocumentSetupParticipant) use that as part of their name. javadoc starts like this for IDocumentSetupParticipant
It's named IToolDetectionParticipant

 * Participates in the setup of a text file buffer document.
 * <p>
 * This interface is the expected interface for extensions provided for the
 * <code>"org.eclipse.core.filebuffers.documentSetup"</code> extension point.
 
Mentioning the extension point in the interface javadoc is a good idea.

Martin

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev