RE: inter project dependencies

Nicola Ken Barozzi wrote:
> 
> I am moving this to the dev list if you don't mind.
> 
> Unico Hommes wrote, On 19/03/2003 12.09:
> > Nicola Ken Barozzi wrote:
> > 
> ...
> >>The only thing that is lacking still, as you correctly point 
> >>out, is the 
> >>classes of the other build result.
> >>
> >>Now, we want to remain near to Gump ways as much as 
> possible. So Gump 
> >>defines dependencies by looking in the <jar> tage of the 
> >>dependent project.
> > 
> > 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?
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.

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

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




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