> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>
> Berin, I'm having problems in >> your mails, do you have a clue why?
No. I am using the plain text mode of Outlook. (I have been trying
to use Mozilla on my XP box, but it has been rebellious).
>
> Anyway, my impression is that circular dependencies are
> BEE-AE-DEE. Bad.
:) Yep.
>
> What we came up with on the krysalis list, is to make javac
> resolve the dependencies itself, and then separate the
> packages when making jars. JDepend shows what the
> dependencies are, so a user knows which packages to use for a
> set of functionality.
>
> Think about compiling JDK with a depchecker...
>
> I honestly think that what Avalin has done with Excalibur is
> really stretching the definition of sofware module a bit too far.
Excalibur's subprojects are supposed to be treated like little mini
projects. Each one should be able to be completely separate from the
others.
>
> What is the *need* for a division of packages in different
> root dirs? Can't just a specializes jar task divide them upon jarring?
Technically yes, but then you loose the mini-project feel, and it is
harder to find holes in documentation, etc.
>
> -oOo-
>
> As for Centipede, the cents should IMO *not* have circular
> dependencies. Even more clear: *not* have dependencies on
> _implementations_.
Absolutely.
>
> The layout.xml file shows a "conceptual" model of a build space.
>
> Taking as an example:
>
> centipede:compile
> junit:test
> centipede:dist
>
> How can the centipede cent and the JUnit cent automatically
> work together?
>
> By defining what directories they need (or suggest) to be
> filled with data before operating.
>
> -compile needs nothing and generates in the classes dir.
> -junit needs the classes dir to work, and generates test
> documentation. -dist suggest all dirs to be filled.
>
> This is the kind of dependency I envision, dependency on the
> *contract*, not the implementation.
>
> In this way I can switch implementations and blah blah blah ;-)
You don't need to tell us ;P
The question is how do you know a contract has been satisfied.
directories, et. al. are weak contracts.
>
> There is also the need to define a "hint" for the targets, so
> that a target is called in a particular contest (compile,
> test, docs...etc).
>
> How does this sound?
Sounds pretty decent. Have you given any thought to using my
approach to detect cyclic dependancies that are not immediately
visible?
For example,
Let's say that we have a build that requires docs, and another
one that has a nasty side affect.
Something along these lines:
centipede:dist
+ foo:dist
+ centipede:docs
+ docgen:createdocs
+ foo:skin
+ centipede:jar
+ junit:test
+ foo:checkall
+ centipede:dist
Probably a *vary* rare occurrence, but you can always be assured
there are no circular dependancies.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
