[Seaside-dev] WAPackage dependencies

[John O'Keefe]

Julian and Lukas -

VA Smalltalk is quite strict about dependencies and complains when they are
not met -- the comment on my package update is an exact copy of this
particular complaint.  Because VA Smalltalk packages for runtime based on
dependencies, it is critical for us to have them right in any package
destined for a runtime application.  For a development time package (such as
a testcase package), these complaint can be (but not neccessarily are) less
important.

Before the advent of WAPackage, I had an equivalent to its dependencies in
the VAPackageExporter (Lukas, you've seen this) which was used to generate
the dependencies when exporting Seaside packages from Squeak to VA
Smalltalk.  With the advent of WAPackage, these dependency definitions have
been reduced to only those that go outside Seaside (such as SUnit and
Refactoring Browser) which I merge with the dependencies from WAPackage when
exporting.

So, I'm not quite sure how to interpret your post.  Did you mean to say that
I should not have modified the dependencies for JQuery-Tests-Core?  If so, I
guess I am still not clear on exactly what the intent of the WAPackage
dependencies is.  I certainly have no intent of subverting the desired use
of WAPackage dependencies, so perhaps I need to change my approach to
generating prerequisites for Seaside packages in VA Smalltalk.  I am open to
suggestions.

John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.


On Thu, Dec 18, 2008 at 5:14 AM, Julian Fitzell <jfitzell at gmail.com> wrote:

> JQuery-Tests-Core-jok.46.mcz
> from Seaside 2.9 by John O'Keefe <john_okeefe at instantiations.com>
> - update dependencies: Seaside-Development is required due to
> referenced class WAPrettyPrintedDocument from
> JQAllTests>>#renderJavascriptOn:
>
> John, the goal is, I think to have the WAPackage dependencies reflect
> functional (or "desired") dependencies and that that information
> combined with static dependency analysis will allow us to (a) create a
> workable load order if possible and by considering the union of the
> two dependency sets (b) spot problems where there are static
> dependencies that should not exist by looking at the difference of the
> one set from the other.
>
> This concept has got a bit muddied though: I was just talking about it
> again with Lukas the other day and he had forgotten we were talking
> about doing that and so was not combining the static dependency info
> into the load order. But I think he was going to try doing that now...
>
> Julian
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20081218/63cb70ef/attachment.htm