Ok - so this is an aspect of modularization, rather than some deranged
bending of package implementation? :D
So if a "module" has public packages A, B and C would it be :
org.apache.harmony.module.A
org.apache.harmony.module.B
org.apache.harmony.module.C
org.apache.harmony.module.internal
not
org.apache.harmony.module.A
org.apache.harmony.module.A.internal
org.apache.harmony.module.B
org.apache.harmony.module.B.internal
org.apache.harmony.module.C
org.apache.harmony.module.C.internal
geir
Tim Ellison wrote:
'.internal.' is used to denote packages containing types that are wholly
the business of a particular module; whereas non-internal packages
contain types that can be called from other modules (e.g. utilities) and
are expected to be stable.
In OSGi speak, we will export all packages that are *not* marked
'.internal.', and all packages that are marked as '.internal.' will not
be exported.
The naming convention is simply our convention to identify
internal-APIs, it is not required by OSGi/Eclipse/...
Regards,
Tim
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
George Harley wrote:
Mikhail Loenko wrote:
Of course, the text module has only "implementation-independent tests
that designed to be run from classpath". For modules that have got
implementation-specific tests then I suppose we could use something
like "org.apache.harmony.[module].tests.impl.[package under test]" or
"org.apache.harmony.[module].tests.internal.[package under test]"
etc. I've got no preference.
I think impl is preferable over internal here, as we already use
internal in our implementation package names to indicate classes
totally internal to that bundle. To also use internal to label tests
that are implementation specific may cause confusion.
I think the whole 'internal' thing is just awful IMO. (Man, it feels
good to stay that...)
Why do we need it? Eclipse? OSGi?
Isn't it pre-supposing a packaging system in the source code structur?
(one that I think is pretty unnatural for java programmers....)
I'm 100% behind offering the Harmony classlibs packaged for OSGi, but
I'm 100% against assuming it's the only way to go...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
