harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: classlib/trunk repository structure
Date Fri, 10 Feb 2006 17:09:51 GMT


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
> 
> 

Mime
View raw message