Re: inter project dependencies

Unico Hommes wrote, On 21/03/2003 17.10:
> 
> Nicola Ken Barozzi wrote:
> 
>>I am moving this to the dev list if you don't mind.

Hmmm, you still replies on the user list ;-)

It's a developer issue, we should really move it there IMHO.

>>Unico Hommes wrote, On 19/03/2003 12.09:
...
>>>
>>>But imagine wanting to have gump do a full 'dist' on 
>>
>>project B, I wouldn't want a 'package' in project A to result 
>>in a full 'dist' on project B. Perhaps it would be better not 
>>to use the gump tag for these dependencies, but just always 
>>call package?
>>
>>Sorry I don't get it. If I do a dist of project B, I can use 
>>the thing 
>>that are in build/B/**, while the package of A is in build/A/**
>>
>>Could you please explain again?
> 
> Well, as I understand, declaring project B having a dependency on
> project A results in the following: 
> If I compile B:
> 'cent -Dproject.name=B compile'
> Centipede looks for an element <ant target="gump" /> in project A and
> calls the target specified there, right?

Ahhh, ok, I get it now.

> Maybe the gump target does a clean, a compile, a test, a forrest.docs,
> etc. while actually I only needed the java files to be compiled and
> possibly packaged. This causes a lot of overhead. Hence my suggestion to
> separate the gump concern. So maybe it should be that calling the
> 'compile' target on B results in centipede calling the 'compile' target
> on A, calling the 'package' target on B results in centipede calling the
> 'package' target on A, etc.

Good point. This is the thing we strarted discussing about some time 
back, it's time to nail it down.

The fact is that there can be three scenarios as you show:

  1 - use the Gump targets
  2 - use a special target just for building the jars for deps
  3 - use the user-specified target

In the first case we are redoing what Gump does but without the full 
compilation of all dependencies (only the ones in the module).
It's not really that useful, it seems,if as you say the targets do all 
sort of things for Gump runs.

In the second case we can add a special target that does only the 
compilation of the jar... but this is still wrong if we call the docs 
target, which does not need the jar.

So what remains is that it uses the target specified during the build.


> This leaves the question of what part of centipede is going to be
> responsible for setting up that part of the classpath. In Nick's
> solution that logic is in getdepend.xsl, and only dependencies declared
> to be version = other than 'supplied' are handled by Ruper. 

Hmmm...

> I actualy
> think that is the correct way because a local project is in a way
> 'supplied', just not as a jar in ./lib . Unless I am missing something
> and there is a specific reason why Ruper should know about that local
> dependency.

Honestly I don't have any strong idea on where it should go... I'd just 
like to see this be something that does not tie too much all the 
components we use to work necessarily together (ie that they can work 
well alone)... ATM the best thing is to make a reasonable decision (also 
implementation-wise) and see how it works. Time will tell.

> <snip/>
> 
>>IIRC in the RuperTask. That's why we need Ruper to be able to get the 
>>jar form the local dirs in the second case scenario.
>>
>>So, recapping, you have basically two possibilities I see ATM:
>>
>>a) when calling the Ant task on the dependent projects in 
>>CentipedeTask, 
>>also add a classpath with the jar specified in the Gump descriptor
>>
>>b) Make Ruper able to get the local tasks by inspecting the 
>>gump descriptor.
>>
>>Please don't hesitate to ask further clarifications to the 
>>dev list :-)

-- 
Nicola Ken Barozzi                   [email protected]
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en