Geir Magnusson Jr wrote: > Ok - so this is an aspect of modularization, rather than some deranged > bending of package implementation? :D
Yes. > So if a "module" has public packages A, B and C would it be : .. and therein lies the problem, there is no such thing as a 'public package' and a 'non-public' package in Java syntax (yet), so we have the naming convention. > 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 Yep. Regards, Tim > 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] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
