Alexey Petrenko wrote:
Geir :
As for the policy doc, why? To match component names to policy
documentation?
Because it is not show the real repository structure...
It's not meant to. The componentization is conceptual, not representing
the literal layout in SVN.
For example...
Contribution policy:
"Division of Repository
=== skipped ===
enhanced/classlib
/applet
/awt
/beans
/...
=== skipped ==="
Real repository:
enhanced/classlib/
enhanced/classlib/branches/ - unspecified but with obvious meaning
enhanced/classlib/tag/ - unspecified but with obvious meaning
enhanced/classlib/trunk/ - unspecified but with obvious meaning
All the directories inside "trunk" are not specified but almost
obvious. And only inside "enhanced/classlib/trunk/modules/" we can
find module names which were mentioned in the policy.
There are all sorts of interesting things in here that we have to deal
with as time goes on. For example, what happens when we branch to do a
release? :)
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"
OK.
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...
But I believe that we need clear decision anyway... To put the native
sources inside the modules or not to put.
I think that they go inside.
I think it will be very useful for developers (who plans to contribute
something to Harmony) to have up to date policy on repository
structure and building process. It will also help for users and fix
developers to understand where to find needed sources.
That's all well and good, but I want to arrive at good solution through
experience that doesn't unncessarily disrupt us.
I think that we're starting to things crystalize.... At some point
we'll say "hey, that works well!" and adjust things to fit.
Now, I don't mean that things are random I don't expect that each module
will be different.... I think that we accept new code, we will be able
to learn something new (maybe) and do some minor adjustments were
possible to existing, or just make the new code conform to what we think
of as best practice.
I know I'm not explaining this well, but I'm not convinved we have
enough of a reason at this point to stop work and move things around,
which will be disruptive...
And my other point that now we got not much sources and it will be
rather easy to adjust them to the policy. When we will have more
modules with much more sources it will be much more hard.
Yes, that's true. I think we just keep this in mind and move
organically. I don't have the answers :)
geir
--
Alexey A. Petrenko
Intel Middleware Products Division
