<div>Julian -</div>
<div> </div>
<div>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?</div>
<div> </div>
<div>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.</div>
<div> <br clear="all">John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.<br><br><br></div>
<div class="gmail_quote">On Thu, Dec 18, 2008 at 10:09 AM, Julian Fitzell <span dir="ltr"><<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">Hey John,<br><br>So, let me try again.<br><br>The goal of WAPackage is to document the dependencies between packages<br>
as a human would understand them (ie. by the design).<br><br>Lukas also has a tool that looks for code dependencies (subclassing,<br>referencing a class, etc).<br><br>There *should* not be any code dependencies that go beyond the<br>
dependencies of WAPackage, and if there are then it is probably a bug.<br>In each case, though, we need to look at it and see whether the bug is<br>that we failed to document a legitimate logical dependency in<br>WAPackage or whether an inadvertent code dependency has been<br>
introduced.<br><br>This allows us to look for "red flags" by taking the set of detected<br>code dependencies and subtracting the set of WAPackage dependencies.<br><br>It also allows us to build a possible load order (even in presence of<br>
incorrect code dependencies) where one exists by taking the union of<br>the two dependency sets. This is what you would need to do to build a<br>load order (at least during development). Lukas has a tool working<br>that does this but I'm not sure exactly what you need to do with the<br>
data. I imagine it can be adapted.<br><br>So yes, we are saying that WAPackage dependencies should not be simply<br>updated to reflect existing dependencies unless they are by-design<br>dependencies that just happened to get missed on WAPackage.<br>
<br>Is that clearer?<br><font color="#888888"><br>Julian<br></font>
<div>
<div></div>
<div class="Wj3C7c"><br>On Thu, Dec 18, 2008 at 2:20 PM, John O'Keefe<br><<a href="mailto:wembley.instantiations@gmail.com">wembley.instantiations@gmail.com</a>> wrote:<br>> Julian and Lukas -<br>><br>> VA Smalltalk is quite strict about dependencies and complains when they are<br>
> not met -- the comment on my package update is an exact copy of this<br>> particular complaint. Because VA Smalltalk packages for runtime based on<br>> dependencies, it is critical for us to have them right in any package<br>
> destined for a runtime application. For a development time package (such as<br>> a testcase package), these complaint can be (but not neccessarily are) less<br>> important.<br>><br>> Before the advent of WAPackage, I had an equivalent to its dependencies in<br>
> the VAPackageExporter (Lukas, you've seen this) which was used to generate<br>> the dependencies when exporting Seaside packages from Squeak to VA<br>> Smalltalk. With the advent of WAPackage, these dependency definitions have<br>
> been reduced to only those that go outside Seaside (such as SUnit and<br>> Refactoring Browser) which I merge with the dependencies from WAPackage when<br>> exporting.<br>><br>> So, I'm not quite sure how to interpret your post. Did you mean to say that<br>
> I should not have modified the dependencies for JQuery-Tests-Core? If so, I<br>> guess I am still not clear on exactly what the intent of the WAPackage<br>> dependencies is. I certainly have no intent of subverting the desired use<br>
> of WAPackage dependencies, so perhaps I need to change my approach to<br>> generating prerequisites for Seaside packages in VA Smalltalk. I am open to<br>> suggestions.<br>><br>> John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.<br>
><br>><br>> On Thu, Dec 18, 2008 at 5:14 AM, Julian Fitzell <<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>> wrote:<br>>><br>>> JQuery-Tests-Core-jok.46.mcz<br>>> from Seaside 2.9 by John O'Keefe <<a href="mailto:john_okeefe@instantiations.com">john_okeefe@instantiations.com</a>><br>
>> - update dependencies: Seaside-Development is required due to<br>>> referenced class WAPrettyPrintedDocument from<br>>> JQAllTests>>#renderJavascriptOn:<br>>><br>>> John, the goal is, I think to have the WAPackage dependencies reflect<br>
>> functional (or "desired") dependencies and that that information<br>>> combined with static dependency analysis will allow us to (a) create a<br>>> workable load order if possible and by considering the union of the<br>
>> two dependency sets (b) spot problems where there are static<br>>> dependencies that should not exist by looking at the difference of the<br>>> one set from the other.<br>>><br>>> This concept has got a bit muddied though: I was just talking about it<br>
>> again with Lukas the other day and he had forgotten we were talking<br>>> about doing that and so was not combining the static dependency info<br>>> into the load order. But I think he was going to try doing that now...<br>
>><br>>> Julian<br>>> _______________________________________________<br>>> seaside-dev mailing list<br>>> <a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
>> <a target="_blank" href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>><br>><br>> _______________________________________________<br>
> seaside-dev mailing list<br>> <a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>> <a target="_blank" href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
><br>><br>_______________________________________________<br>seaside-dev mailing list<br><a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br><a target="_blank" href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</div></div></blockquote></div><br>