I think it's an excellent idea to separate the API and internal
packages. Keep in mind though that if one of your plugins uses
packages from another of your plugins, that is considered public API.
What this means effectively, is that if for the next release we decide
that we want the APIs to remain backward compatible, we will be limited
in what kinds of changes we make to the APIs, and we indicate this to
the world by issuing a point release (e.g. 1.1). However if we decide
that we don't care if adopters of our technology will be broken by the
APIs. We can issue a major release (2.0). Some projects are very
conservative, e.g. Eclipse Platform and they issue major releases only
every few years. Some projects, such as CDT issue major releases just
about every year.
We (the DD community) can decide how important API compatibility is for
us and thus what kind of release we want to have next.
Anthony Berent wrote:
Actually I do not believe that you need to have "dsdp" in the package
names. "dd" is sufficient so I think the ipxact packages are already
that IP-XACT 1.4 has been released, I am starting to think about
checking in the IP-XACT 1.4 version of the editor.
have just been reading the Eclipse naming conventions (http://wiki.eclipse.org/Naming_Conventions)
and I think that, since I don't export any public APIs, I should be
renaming all the packages in the IP-XACT editor plugins as internal
packages before checking them in. My understanding from this page is
that the subproject here is "org.eclipse.dsdp.dd", and that as such the
packages should be named "org.eclipse.dsdp.dd.internal...", so, for
example, the editor core document package would become
I need to do this renaming?
I putting the "internal" in the right place in the names?
As far as the "internal", this package name should come after the
component, i.e. org.eclipse.dd.ipxact.internal.editor.core.document.
Jus as important as using the "internal" in the package name, is
marking the package as internal in the exported packages of the plugin.
It's definitely not too late. Technically we have until M6 to make API
changes. In M7 API changes will require PMC approval. So now is a
perfectly good time to do this package reorganization.
I am also starting to think about what APIs the editor could usefully
export. It is obviously too late to make any of these official APIs for
Ganymede, but there seems to be a convention that preliminary versions
of APIs can be exported with a package name including
"internal.provisional.". Is this your understanding, and if so would
there be any objection to including some such APIs in the editor?
+44 1223 400763
IMPORTANT NOTICE: The
contents of this email and any attachments are confidential and may
also be privileged. If you are not the intended recipient, please
notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information
in any medium. Thank you.
dsdp-dd-dev mailing list