Aleksandar Kurtakov wrote on 03/22/2012 03:22:54 PM:
> I fully support the all-internal approach and after doing that to
> the man-page and rpmstubby projects they have two exported classes
> each. In the rpmstubby case it even led to simplifying/unifying the
codebase.
> But I think that we should use the internal package name convention
> wherever possible to make clear difference and not make the javadoc
> building more complicated. I would even ask for renaming things that
> are not supposed to be api to internal or provisional(if you prefer)
> and export the package(if you have to) and mark as an x-internal.
> What we have in non internal(provisional) packages should really be API.
Personally I completely agree with you on the internal package naming. I
know opinions vary though, and the idea of renaming all your packages can
be daunting, so I wanted to throw out lighter weight options. In Eclipse
project we have used "provisional" in package names in the past, for APIs
that were nearly done but not 100% ready. We have been moving away from
that mainly because of the pain it causes the early adopters when we
rename a package to remove provisional that would have otherwise stayed
the same. Again, there are different opinions out there on this - the most
important thing is documenting whatever your convention is so downstream
consumers know what to expect.
John
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
