I meant only one level of nesting

>   MagmaServer
>     requires MagmaClient
>     and Ma Client Server
>     and Ma Object Serialization


and not

>   MagmaClient
>     requires Ma Client Server
>     and Ma Object Serialization

after I'm not sure that this is scaling well but more that inside 
dependencies.
We are trying for SWII and we will learn in the process :)

Stef

On 3 nov. 04, at 22:19, Chris Muller wrote:

>
> Hi Stéphane, let me know if I'm interpreting your suggestion 
> correctly.  Are
> you saying to make each direct-prerequisite *and* 
> indirect-prerequisite a
> direct-prerequisite.  Thus, instead of having:
>
>   MagmaServer
>     requires MagmaClient
>       requires Ma Client Server
>         requires Ma Object Serialization
>
> I would have:
>
>   MagmaServer
>     requires MagmaClient
>     and Ma Client Server
>     and Ma Object Serialization
>
>   MagmaClient
>     requires Ma Client Server
>     and Ma Object Serialization
>
>   Ma Client Server
>     requires Ma Object Serialization
>
> and in so keeping no more than one-level of prerequisites for any 
> particular
> package, this would seem to clear up the problem as you said.
>
> Interesting, that sounds pretty good, but please tell me what you and,
> hopefully Avi if this ends up being in Monticello, think of this too.  
> What if,
> upon marking a package dirty, it finds all packages that have that 
> package as a
> direct-prerequisite and marks them dirty too, under the same process,
> therefore, *its* parents will also be marked dirty, all the way up the 
> chain.
>
> So, in the original example:
>
>   MagmaServer
>     requires MagmaClient
>       requires Ma Client Server
>         requires Ma Object Serialization
>
> Marking Ma Object Serialization dirty causes Ma Client Server to be 
> marked
> dirty causes MagmaClient causes MagmaServer.
>
> This may have a slight additional benefit that each package up the 
> chain which
> also serves as an independently usable package (i.e., Ma Client 
> Server) will
> have the latest version saved without having to force it dirty through 
> some
> "non-change" (i.e., add / delete a space in some method, save to force 
> package
> dirty, then save package).  Instead, it's all automatic.
>
> I think you pulled me back to reality in terms of using prereqs.  I 
> need the
> tool to remember package-version compatibility, so I don't know what I 
> was
> thinking when I suggested the possibility of undefining all of my 
> pre-reqs.
>
>
>
> --- stéphane ducasse <ducasse at iam.unibe.ch> wrote:
>
>> chris
>>
>> I do not know if this is the solution but why not having a separate 
>> and
>> empty package (called map after)
>>
>> MagmaServer 23
>> 	requires MagmaClient.24
>> 	requires MaClient.17
>> 	requires Ma Object Serialization 21
>>
>> Then when you change
>>
>> MagmaServer 24
>> 	requires MagmaClient.24
>> 	requires MaClient.17
>> 	requires Ma Object Serialization 26
>>
>> This way you always control a complete coherent pieces of working
>> together packages
>> but you do not have the problems you encountered.
>>
>> We will try to develop SmallWiki two this way and try to minimise
>> hardcoding dependencies
>> inside the packages.
>>
>> Note that ned at OOPSLA suggested to me not to have nested map because
>> this way
>> you are sure that you do not get twice and child with different 
>> version
>> in separated nested maps.
>>
>> If you used this way of structuring your code I would appreciate that
>> you let us know if this is working.
>>
>> Stef
>