[Seaside-dev] WAPackage dependencies

[Julian Fitzell]

Hey John,

So, let me try again.

The goal of WAPackage is to document the dependencies between packages
as a human would understand them (ie. by the design).

Lukas also has a tool that looks for code dependencies (subclassing,
referencing a class, etc).

There *should* not be any code dependencies that go beyond the
dependencies of WAPackage, and if there are then it is probably a bug.
In each case, though, we need to look at it and see whether the bug is
that we failed to document a legitimate logical dependency in
WAPackage or whether an inadvertent code dependency has been
introduced.

This allows us to look for "red flags" by taking the set of detected
code dependencies and subtracting the set of WAPackage dependencies.

It also allows us to build a possible load order (even in presence of
incorrect code dependencies) where one exists by taking the union of
the two dependency sets. This is what you would need to do to build a
load order (at least during development). Lukas has a tool working
that does this but I'm not sure exactly what you need to do with the
data. I imagine it can be adapted.

So yes, we are saying that WAPackage dependencies should not be simply
updated to reflect existing dependencies unless they are by-design
dependencies that just happened to get missed on WAPackage.

Is that clearer?

Julian

On Thu, Dec 18, 2008 at 2:20 PM, John O'Keefe
<wembley.instantiations at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>