Alexey Petrenko wrote:
Isn't it a good time to normalize classlib/trunk repository structure
and update "Apache Harmony Contribution Policy" document
(http://incubator.apache.org/harmony/contribution_policy.html) while
we got small number of modules?
I think that given the fact that everyone is short on cycles as well as
certainty, I'd like to see us test some alternative approaches before we
decide on the One Tru Way and start moving things.
As for the policy doc, why? To match component names to policy
documentation?
Here is what I mean...
1. There is classlib/trunk/native-src directory. README says:
"native-src contains native source files only". So it looks like
correct place for ALL the native sources.
If so why we got native sources in
classlib/trunk/modules/security2/src/linux/other/?
I'm not at all convinced that the natives should be separate from the
modules.
And why we got
additional java subdirectory in every main directory?
It's the language the stuff below is written in.
I think that we should store native sources under modules directory
with all other module sources. modules/modulename/src/main/native
looks like a good place for this. It will make looking for module
sources much easier.
yes - and I'm sure it's "on the list"
2. It's not clear where the system specific java sources should be stored.
I think modules/modulename/src/linux and
modules/modulename/src/windows will be a good place.
Mmmmm. We talked about this before.... I think the thought was to group
the natives for a module together under something to prevent src/ having
too many children...
I'll go look back in archives.
3. It's not clear what should be placed in modules/modulename/src/main
directory. Main sources? What is main sources? May be it's system
independent sources? If so may be common it better name for this
directory?
It's to distinguish from "test"
So I suggest the following structure for sources:
classlib/trunk/modules/modulename/src/ - all the sources for
"modulename" are here.
classlib/trunk/modules/modulename/src/common - all the system
independent sources are here
classlib/trunk/modules/modulename/src/common/java - common java sources
classlib/trunk/modules/modulename/src/common/native - common native sources
classlib/trunk/modules/modulename/src/linux/java - linux specific java sources
classlib/trunk/modules/modulename/src/linux/native - linux specific
native sources
classlib/trunk/modules/modulename/src/windows/java - windows specific
java sources
classlib/trunk/modules/modulename/src/windows/native - windows
specific native sources
I think this is like what we came up with on the list earlier. I had a
few concerns :
1) That when working in common IDEs, that it was convenient to work with.
2) That build scripts were parametized and simple - so that you could
specify a platform, and it would build for that platform. w/o lots of
special cases or duplication in the build scripts.
The last question is platform specific sources (IA32, IA64 and so
on)... We can easily put them under windows/IA32 or so...
That's where I fear irregularity, and where this gets harder. Because
there are going to be some platforms where there is divisions (like
windows - ia32, ia64) and some not (say, OSX, although now they have PPC
and Intel)
So what happens with platform common code?
windows/common
/ia32
/ia64
?
As long as the build system and test system is easily parameterized for
maintainabliity, I'm happy w/ something like this.
Any thoughts?
When some decision will be agreed or current structure become clear I
will prepare patch for "Contribution Policy"... If nobody mind.
Hang on. before you do that, care to explain a bit why?
--
Alexey A. Petrenko
Intel Middleware Products Division
