Lagoon: App dependent on non-distributables

I'm trying to deploy an application using the Lagoon Wizard launched via the
Package Browser.  Prior to the creation of the exe, the wizard displays a
message saying that the app is dependent on non-distributable tools or
classes.  It identifies the package "Development System".

Looking at the prerequisites for some of my packages, I can see that I do,
in fact, have some dependencies on class SmalltalkSystem as some of my
classes add themselves to the system folder within #initialize.  This
behavior obviously isn't needed at runtime so I guess I can simply put such
methods in the "must strip" category to remove the dependency.  Does anyone
know if this will prevent the "non-distributable" warning message from
appearing during deployment?

Or, is there a better approach to solving this problem?  I was thinking, for
example, of creating a "To be stripped" package and assigning all of the
"problem" devl-time-only methods in my system to that package.  That
approach might create some problems though for a class method like
#initialize.

Thanks.

Chris Hayes

Chris,

> Or, is there a better approach to solving this problem?  I was thinking,
for
> example, of creating a "To be stripped" package and assigning all of the
> "problem" devl-time-only methods in my system to that package.  That
> approach might create some problems though for a class method like
> #initialize.

An alternative way to look at it: if you are having to initialize classes in
a deployed app, that might suggest that you have some behavior that really
belongs on the instance side of another, perhaps singleton, object???

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:9u5ce0$6d001$[hidden email]... in
> a deployed app, that might suggest that you have some behavior that really
> belongs on the instance side of another, perhaps singleton, object???
>

Well, that's just it.  The behavior in these class initialize methods
*isn't* required at runtime.  Their only purpose is to add some subfolders
and items to Dolphin's system folder (e.g., see
PackageBrowserShell(class)>>initialize).  That's why I don't want/need these
methods included in the deployed app.  (I do, however, need the classes
themselves and the rest of their methods at runtime).

Come to think of it, it looks like PackageBrowserShell(class)>>initialize
uses "Smalltalk developmentSystem" rather than "SmalltalkSystem current"
(which is what I'm using).  I guess using a level of indirection like that
would be one way to get around the problem.

Thanks.

Chris

Chris

You wrote in message
news:7peN7.510$[hidden email]...
> I'm trying to deploy an application using the Lagoon Wizard launched via
the
> Package Browser.  Prior to the creation of the exe, the wizard displays a
> message saying that the app is dependent on non-distributable tools or
> classes.  It identifies the package "Development System".
>
> Looking at the prerequisites for some of my packages, I can see that I do,
> in fact, have some dependencies on class SmalltalkSystem as some of my
> classes add themselves to the system folder within #initialize.  This
> behavior obviously isn't needed at runtime so I guess I can simply put
such
> methods in the "must strip" category to remove the dependency.  Does
anyone
> know if this will prevent the "non-distributable" warning message from
> appearing during deployment?
>
> Or, is there a better approach to solving this problem?  I was thinking,
for
> example, of creating a "To be stripped" package and assigning all of the
> "problem" devl-time-only methods in my system to that package.  That
> approach might create some problems though for a class method like
> #initialize.

Yup. Either approach will work. If it's just a method or two, we normally
put them in the 'must strip' category, since those are removed before the
package pre-reqs are traced to identify dependencies on the development
system. If the "development" methods are more extensive (or if there are
development classes) we now tend to break those out into separate packages,
and indeed D5 contains several such packages.

Regards

Blair