Extended Package concept

Hi all,

        we make intensive use of Package Browser in each project developed with
DST, and we have to be very carefully for the dependencies we generate
between the packages that contents the project.

        So...   who content the project?

        Using STS - Source Tracking System from David Gorisek we have a Project
Manager. It manages a Project, that is a list of Packages *loadables* in
certain order (taking care of prerrequisites).

        This is the question:

        Could the project concept be a natural extension of a package? I mean, if
the Package Browser have a tree instead of a list, then you could see
things as a whole when you got to manage big projets. Let say 20 subPacks
that brings solutions for different and relatively independent sub systems
into the whole application. The prerrequisites could be more intiutive (and
that's not a little thing).

        just to share, best regards..

Seb

Smalltalkiano <[hidden email]> wrote in message
news:a5lngf$89shn$[hidden email]...
...
>         Could the project concept be a natural extension of a package? I
mean, if
> the Package Browser have a tree instead of a list, then you could see
> things as a whole when you got to manage big projets. Let say 20 subPacks
> that brings solutions for different and relatively independent sub systems
> into the whole application. The prerrequisites could be more intiutive
(and
> that's not a little thing).

I think we shall see something like this in Dolphin version 5 when it is
released.  Andy posted a message in September

http://groups.google.com/groups?hl=en&selm=9ohoq8%24dc0m7%241%40ID-51044.new
s.dfncis.de ) explaining the new look, with some cool screen shots.  The
urls in that message no longer work, but I think you can see the same thing
here http://www.object-arts.com/Dolphin5/PB.gif .

When I saw the screen I was tempted to offer some feedback, but decided to
wait until I actually had a chance to use it first. ;)  I like the changes,
and I think it would be cool if there were a better way of permitting the
system to cope with cyclical package references.

I too use STS, and have a lot of packages.  I also have some cyclical
references.  Since I use STS I do not worry about being able to save to PAC
files.  The one problem I had was when it came time to deploy an application
that had some cyclical references.  I wrote an ImageStripper subclass to
handle that (it would still uninstall all the packages it could, but remove
any cyclical packages on a class by class basis).

Chris

Christopher J. Demers wrote:
http://groups.google.com/groups?hl=en&selm=9ohoq8%24dc0m7%241%40ID-51044.new
Hi Cris,
 
 you can save the packs, deploy the executable an keep all dependences
*legally* maintained making use of loosed methods. Imagine the mamushka
dolls (the dependent packages), the loosedmethods provides you the
connection between them and everybody happy.

regards

Seb