Deployment too cant locate package file

Hello all,

I'm trying to deploy an application on Dolphin Smalltalk Professional 5.1.4.

while 'removing unwanted packages' the deployment tool reports that it can't
find the file:
    [some abs path]\Web_Tools fix-deploy\Objectech\Data
ClassificationTools\GenreTool.pac

The actual path for the package file is:
    [some abs path]\Web_Tools fix-deploy\GenreTool.pac

The image resident package instance has the correct path as its
packageFileName. This path conflicts with the packagePathName instance
variable - which is the path that is reported as failing above...

Why are there two paths & why are they out-of-synch?

I build the image from a .dpl file generated & loaded using Jochen Reikhof's
Package Manager. This all worked fine about 6 months ago.

--Peter Goodall

Hi,
I didn't get any replies - and I'm still stuck. I cannot browser
pre-requistes of packages in the package browser for the same reason.

The problem seems to be in ClassLocator>>findOrImportForeignClass which
seems too difficult to trace. If anyone knows where to look to fix this
please help.

--Peter Goodall

"peterg" <[hidden email]> wrote in message
news:419aa72c$0$24377$[hidden email]...
> Hello all,
>
> I'm trying to deploy an application on Dolphin Smalltalk Professional
5.1.4.
>
> while 'removing unwanted packages' the deployment tool reports that it
can't Reikhof's
> Package Manager. This all worked fine about 6 months ago.
>
> --Peter Goodall
>
>

Peter,

Speaking just for myself, I didn't respond because I do not have a clue
what is wrong.  With that said, and no offense to Jochen, let me start
out by suspecting his package manager.  I get nervous about anything
that "messes with" source code.  That combined with the fact that you
are having trouble with packages, well, that's the place I would start.

As far as fixing the problem, if you can turn Ian's Chunk Browser loose
on the package files, mildly corrupted or not, you can probably have a
clean image up and running in short order.  Make a new directory, put
the clean install files (source, image, changes) there, copy/tweak any
shortcut that you use to start Dolphin, and have at it with the CB.
Make backups of everything first, of course, and remember that you need
to archive the source, image, and change files together.  If you are
unclear about it, _please_ post questions.

OA might be able to help you with understanding of the lazy
initialization that goes on in packages, and how to "bang on the box" to
get them to fix themselves.  No guarantees though.

You might also (after a backup!) create a new package and try to empty
one of the offenders into it, and then remove the new empty
(troublesome) package.

Sorry I can't be of any real help, except to advise that you make a
backup :)

Have a good one,

Bill

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

Peter,

>> Why are there two paths & why are they out-of-synch?

The only time I can remember seeing anything like this is when a packages
prerequisite list get confused after one of it's prequisite files has been
moved and the package hasn't been resaved to remember the new path.

The easiest way to check for this sort of thing is to manually open each of
your packages in your application (either in the ChunkBrowser or a simple
TextEditor) and look for anything odd in the bit that comes after...

package setPrerequisites:

This will be found quite near the start of the file as part of chunk #1.  It
should be a list of paths to all the packages prerequisite files.

I _think_ that's the only other place, other than the package's stored path,
that paths are mentioned in a package.

--
Ian


Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Hi,

Thanks to Bill and Ian. I suspect the problem was to do with relocation of
the packages as Ian suggested. The source mgmt code in question is v. hard
to deal with - I fear its setup to do more than is actually used.

I rolled back my image to patch-level 3 & reloaded my config - and it all
works again. Can't be sure what the prob was exacltly - because of the
impenetrability of the code. So it works now - thanks...

BTW I've been using SubVersion and Tortoise SVN for managing configs
recently, and am very happy with it.
http://subversion.tigris.org/
http://svnbook.red-bean.com/


--Peter Goodall