[Seaside-dev] WAPackage dependencies

[John O'Keefe]

Julian -

OK, I think I understand.  You are saying that WAPackage *should* reflect
all the *legitimate* dependencies *within* Seaside (I added this last caveat
based on our earlier discussions).  When WAPackage does not accurately
reflect these dependencies, it can be either an error in the WAPackage
dependency description *or* an error in the actual interrelationship of the
code.  Right?

I don't think I need Lukas' static analysis output since VA Smalltalk will
alert me (sometimes quite forcefully!) if the dependencies are wrong.  Since
I already have a mechanism to add dependencies that are not reflected in
WAPackage, I will use this mechanism to work-around any existing mismatches
in the WAPackage dependencies.

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


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

> 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
> >
> >
> _______________________________________________
> 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/4ffc63ec/attachment-0001.htm