On Thu, Sep 17, 2009 at 21:29, Wei Tan <[email protected]> wrote:
> 1. Maven manages the build time dependency, and it has its own method to
> resolve conflicts (i.e., for transit dependency conflicts, it will pick
> up the one nearest one in the dependency tree).

Right, or it might even be the newest one.. would need to check.

> 2. It is up to the run-time mechanism to interpret and enforce the
> dependency defined in Maven poms. The way you enforce it in Raven now is,

Correct again.

> 1) for each pom you have an individual classloader and different
> classloaders can load different versions of the same class. This is the
> way through which you make your plug-in framework powerful  for
> virtually "anything".

Well.. :)

> 2) in the meanwhile, the classloader of a child pom (p1) can "see" the
> classes in the classloader of its "parent poms" (p2) (but not the
> "sibling poms"??). If both p1 and p2 depends on a given artifact (say
> p3) with the same version, p1 will just use the p3 which is already
> loaded by p2 (but NOT load p3 again in its own classloader). Otherwise,
> if  p1 needs p3 but with a different version, it will add this different
> p3 into its own classloader and  ignore the p3 which is already loaded
> by p2.

Just two clarifications for our readers. By 'parent' and 'child' here,
we are not talking about the POM <parent> mechanism. Our 'parent' here
is someone who is depending on a 'child'.

No, the child p1 can neither see it's parent p2 or it's sibling p3. p3
might be able to see p1 if it depends on it, and p2 would be able to
see all three.

Or in other words - a POM can only see it's direct dependencies, and
their transient dependencies, but can't see those that depend upon him
(that would form a loop).


Now that's not totally true, we added some kind of loop-support to
Raven, but you would have trouble building it as Maven does not like
such loops.


>   Just want to confirm if I understand the secret of Raven correctly! :-)

We're going deep into the dungeons now..




-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
taverna-hackers mailing list
[email protected]
Web site: http://www.taverna.org.uk
Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/
Developers Guide: http://www.mygrid.org.uk/tools/developer-information

Reply via email to