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 17:02:06 GMT
Berin, I'm having problems in >> your mails, do you have a clue why?

Anyway, my impression is that circular dependencies are BEE-AE-DEE. Bad.

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.

What is the *need* for a division of packages in different root dirs? Can't
just a specializes jar task divide them upon jarring?

                   -oOo-

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

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

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?

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

----- Original Message -----
From: "Berin Loritsch" <bloritsch@apache.org>
To: "Avalon Developer's List" <avalon-dev@jakarta.apache.org>;
<krysalis-developers@lists.sourceforge.net>
Sent: Thursday, May 09, 2002 6:39 PM
Subject: cleaning up interdependancies


I am posting this to both Avalon and Krysalis because we suffer from the
same fundamental problem.  Excalibur has a recursive build feature for
dependant projects (Is this something centipede can use?), and Centipede
has the need to resolve Cents dynamically.

Another place where this problem occurred (in the past it is resolved
now)
is in Cocoon's XSP engine.  The fundamental problem was that we needed
to
order the XSP logicsheet dependancies without explicitly declaring them
in
the XSP page.  We also did not want to depend on the order of the
namespace
declaration.

An example would be if I wrote my own custom logicsheet, which used the
esql logicsheet, which used the util logicsheet, which used the root
XSP logicsheet.  I should only have to declare the page as an XSP
page and declare the namespace for my logicsheet.  Cocoon's XSP engine
should perform the resolution.

The approach developed between myself and Davinum Srinivas (Dims for
short)
was to preload the dependancies, and order them.  If my logicsheet said
that
it needed ESQL and Util, the engine would place my logicheet first in
the
list, and then add Util and ESQL in no guaranteed order.  If ESQL then
said
it needed Util, then the engine would make sure that Util was applied
after
ESQL.  The only template that was guaranteed to be last was the XSP
template.

In essence, the List was populated something like this:

MyLogic
  + Util-------+
  + ESQL       | (it was needed further down the dependancy chain)
      + Util <-+
XSP

The guarantee was that each logicsheet was applied once and only once.
It
also guaranteed that it was placed where it was needed.

Now, Avalon and Centipede have slightly different requirements, but the
same type of approach would help both projects.

Avalon Excalibur's build system needs two new Ant tasks: depcheck, and
depbuild.  Depcheck would check a project descriptor for the dependancy
names, their location, and where the jars are created.  Depcheck will
decend the dependancy hierarchy and find circular dependancies--throwing
an error if it is detected.  Depbuild will use the dependancy list
created
by Depcheck, purge duplicates, and arrange the build order so that the
base dependancies are built first, there is no unnecessary duplication
of builds, and the system is much easier to come to grips with.

A verbose Ant output would be something like this:

[depcheck] Finding dependancies:
[depcheck]
[depcheck] fortress
[depcheck]   + mpool
[depcheck]       + event
[depcheck]       + Framework
[depcheck]   + event
[depcheck]   + logger
[depcheck]       + Framework
[depcheck]       + Logkit
[depcheck]   + etc...

....

[depbuild] Logkit
[depbuild] Framework
[depbuild] logger
[depbuild] event
[depbuild] mpool
[depbuild] etc....


For Centipede, the resolution of build tasks should be done before
they are executed.  That way, it can figure out which cents need
to be downloaded, which cents need other cents, and can detect
circular dependancies which will help cent developers.

A cent circular dependancy would be defined as:

centipede:compile
junit:test
centipede:compile

And it would not be defined as:

centipede:compile
junit:test
centipede:dist

Do you think that could help things out?


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


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




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