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