avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@apache.org>
Subject Re: cleaning up interdependancies
Date Thu, 09 May 2002 21:07:58 GMT
[A note to Leo: keep trying, I'm morally with you :-)
I don't know why you get a nasty exception with the style task and Xalan
2.2.0, try 2.3.1 instead]

From: "Berin Loritsch" <bloritsch@apache.org>

> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > 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).

O well, will do by hand then :-/

> > 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.

Miniprojects. Bah, don't like it much, for me miniprojects are packages and
viceversa.
I still have to understand the need to do this...
... till I don't see it, I will not be much happy to put this feature in
Centipede, because how can I do a good job if I don't know the reason?


> > 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.

Mini-project feel...
So it's a matter of taste, not a way of closing doors one another...
Hmmm, starting to understand...

> >                    -oOo-
> >
> > As for Centipede, the cents should IMO *not* have circular
> > dependencies. Even more clear: *not* have dependencies on
> > _implementations_.
>
> Absolutely.

Good, I was a bit afraid this was not agreed upon, I guess I totally
misunderstood what the depchecker is for.

It's more a warning system than a build tool, right? Something that helps
keep contracts between miniprojects.

But then why not copy all miniprojects in a single dir, compile all of them
with java and have JDepend tell you the dependencies? In this way the build
should never break because of circular dependencies, but you still get the
info...

> > 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

That's why I put the "blah blah blah"  ;-)

> The question is how do you know a contract has been satisfied.
> directories, et. al. are weak contracts.

Yes, this is a very important point, and I am happy to discuss it with you
guys :-)

What contract could I use?
Could I get away with specifying that the contents of that dir also comply
with a certain filename-fileextension-contenttype pattern? (ie all html, all
xml, xml or gifs, xml with certain DTDs, ...)

> > 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.

Very nice explanation, indeed.
Yes, you got me ;-)

Ok, now I see the need, and I'm starting to understand the miniproject
approach.

I really think we can make centipede run on the Excalibur stuff, and put the
depchecker in Centipede.

Gee, coooool!  :-D

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message