Package dependencies

Hi,

I've started with one package, but as the number of classes grew I
rearranged them into different packages.

So now I've got:

        MyApplication
        MyApplicationUI
        MyApplicationDomainModels
        MyApplicationDomainModelBrokers
        etc.


When I try to save the packages, well any of those, I get a "Package
won't save" error because of unresolved dependencies.

The only way I managed to save them was to move methods of a class in
one package to another package.

The problem with that though is that certain packages will get stripped
away during deployment.

Should I, instead of moving methods pretty arbitrarily around just in
order to save the package, keep the methods in the package where also
the class is contained and resolve the dependency issue by using
pre-install scripts? (Which I have no clue how that is done).

Or should I put these dozen of classes back into one package?

Günther

Günther,

> Should I, instead of moving methods pretty arbitrarily around just in
> order to save the package, keep the methods in the package where also
> the class is contained and resolve the dependency issue by using
> pre-install scripts? (Which I have no clue how that is done).
>
> Or should I put these dozen of classes back into one package?

Probably not the latter.  FWIW, this gets easier to fix over time.
Remember that you can save your image and make backups of
image/changes/sources to protect your work while you sort out the
problems.  Search the archives for prerequisites, cyclic, cycle,
packages, etc., and you will turn up lots of advice for how to proceed,
including instructions for using the prerequisites tab (especially the
status icons) in the package browser.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Günther Schmidt" <[hidden email]> wrote in message
news:[hidden email]...
As Bill says, you need to get a feeling for it, though it might never be
perfect like in my case. But generally first you need to start to think of
packages not as functional units, but units of modularization or packaging.
Which set of classes and methods are self standing, and meaningfull
partition for distribution? Usually this will lead to packages that have no
cyclic dependencies, or a few of them that can be resolved by moving a few
methods.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

Günther Schmidt wrote:

Right.

So open up the PackageBrowser.
Select your directory, and one of your packages.

Pick the 'prerequisites' tab.

Select the root of the tree.
Right click, picking *Show Status Icons*.

Green - you can save this package,
Red - there are unresolved dependencies.
On the red ones, open the tree, see what
each conflict is.

Conflicts are typically caused by either an
(unnoticed) circularity (Pkg A needs Pkg B needs C needs A),
and/or a hard reference to a class that needs to be a parameter
instead.  The other issue is "unpackaged" classes - just need
to declare which package they should be in. Select a package,
right click, pick *Add Uncommited Class* to see a list of
Classes you haven't yet declared a location for.

When you've fixed all the above issues for a package,
the icon turns green, and you can save it.


>
> The only way I managed to save them was to move methods of a class in
> one package to another package.
>
> The problem with that though is that certain packages will get stripped
> away during deployment.


Make sure you have "actual" references to everything you need
(as opposed to references "constructed" from string parts).

You might want a "master" package that references all the others,
to ensure that what you need isn't stripped, (until you don't
need it anymore).


Regards,

-cstb


>
> Should I, instead of moving methods pretty arbitrarily around just in
> order to save the package, keep the methods in the package where also
> the class is contained and resolve the dependency issue by using
> pre-install scripts? (Which I have no clue how that is done).
>
> Or should I put these dozen of classes back into one package?
>
> Günther