Hi Stian,
Thanks a lot for your detailed explanation. The information I get
now is:
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).
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,
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".
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 want to confirm if I understand the secret of Raven correctly! :-)
Best regards,
Wei
Stian Soiland-Reyes wrote:
> On Wed, Sep 16, 2009 at 17:39, Wei Tan <[email protected]> wrote:
>
>> 1. I compiled my plug-in which depends on a.b.c.Interface 0.7-SNAPSHOT.
>> When workbench load it, the classloader of the plug-in
>> (say urlclassloa...@1239812389) will load the 0.7-SNAPSHOT jar. The
>> classloader of the workbench (say urlclassloa...@532143)
>> has loaded 0.6 jar and therefore it knows that my plug-in does not
>> implement the right interface in 0.6 jar.
>>
>
> Almost correct, except as it is now there is no actual plugin classloader, a
> plugin is just a list of independent maven artifacts which are added to the
> pool, with one classloader per artifact. If two plugins specify the same
> artifact, there will only be one classloader.
>
> The way Tom did this in the platform was one classloader per plugin, which
> is much easier to keep track of for the plugin developer, but introduces
> other issues, like what happens if a plugin wants to depend on another
> plugin, or if a plugin comes with an API that a third plugin can connect
> to..
>
> Not sure exactly how this will be with OSGi world yet (Alan has had a deeped
> look at this), but the good advantage there is that we would not be alone,
> we would have thousands of other developers using the same framework - hence
> the current plan is for after 2.1 to move the workbench directly to OSGi -
> but picking up things we learnt from the platform work and integrating the
> two code bases.
>
>
>
>> 2. I compiled my plug-in which depends on a.b.c.Interface 0.6. When
>> workbench load this plug-in, since 0.6 jar is already loaded
>> by the classloader of the workbench (urlclassloa...@532143) so that the
>> plug-in classloader (say urlclassloa...@1239812389 )
>> will see and use it. This means that the plug-in classloader will NOT
>> load the 0.6 jar again (correct?) but use the 0.6 jar which is already
>> loaded (by another classloader).
>>
>
> Correct, as it stands there's only one classloader per artifact, and it will
> be reused when possible.
>
>
>
>> In this case the workbench knows that the plug-in implements the right
>> interface (a.b.c.Interface in urlclassloa...@532143).
>>
>
> Exactly, so you get that advantage when talking about an interface or
> superclass. But the downside is that if your plugin is just using some
> library, and if it did some messing about with static methods/fields, say
> setting some global Axis configuration, the effect would be like in
> 'classical' Java, that such changes would affect the whole system - or at
> least everyone using that version of that library.
>
>
>> My understanding is from your words saying that " that a classloader
>> would also be able to see classes from those classloaders". Suppose
>> there is a pom
>> tree like this p1-->p2 (i.e., p1 depends on p2). If both p1 and p2
>> depends on p3, and the classloader of p1 already loaded the artifact
>> defined by p3, then
>> p2 will NOT load p3 again but just use the one that is loaded by p1?
>> In my case, p1 is the workbench (or some artifacts in the workbench that
>> depends on the 0.6 jar), p2 is my plug-in, and p3 is the 0.6 jar.
>> Is that correct? :-)
>>
>
> Yes, you would get a classloader tree out of it:
>
> p1 --> p2 ---> p3 \ ^
> \______________|
>
>
> As long as these trees are 'consistent' (ie. don't have the same class name
> twice) everything should work be fine.
>
>
> In addition we have the SPI registries. They work by having interfaces that
> plugins and components can implement, and they list their implementation
> classname in a resource file
> META-INF/services/net.sf.taverna.t2.blah.TheInterface
>
> The way the SPI registries work is that some user of the interface, say the
> menu manager, makes an SPI registry for a specific interface. The registry
> will then scan through ALL loaded artifacts (ie. from all plugins), and from
> each of those classloaders look up that resource file (depending on which
> interface the registry is over). It will then attempt to load the listed
> classes from that classloader, and the collected list of classes found in
> all of these are available to whoever made the registry. If the registry is
> an instance registry, for each class a single instance will be made in the
> registry, if it is a class registry, only the classes are listed. (Most of
> our registries are instance registries)
>
> Typically these registries are singletons so they can be accessed from
> several places.
>
> And this is how we find menues, available services, file formats,
> perspectives, individual components within the perspectives, contextual
> views, etc. - making all of these extensible by plugins.
>
> The main danger here is as we said about the interfaces themselves, Raven
> does not know that an artifact 'contains interfaces' and treats them just
> like any other class, meaning that if an artifact lists an SPI
> implementation of a certain interface, that class will be attempted loaded
> for such an SPI registry. Our current registries don't understand these
> versions, and so get very confused when an instance comes along that
> implements the 'wrong' interface. If you are unlucky you could actually
> end up with a full parallel world of two workbench APIs mixed together, only
> differing by their Maven version number - but with only one of them shown on
> screen - and the developer scratching his head over why his plugin is not
> showing up...
>
>
>> I wonder if there should be a top pom for each Taverna release and it
>> defines all the properties that every plug-in should use.
>>
>
> That was the 'top' POM, but it's not on the top Maven-like, because that
> would mean that for every time we change anything we would have to change
> the version of the parent, and then the version of his parent again, and
> then all the children of those parents and so on, rippling through, meaning
> that everything would always have to change for any tiny update.
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® 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-12, 2009. Register now!
> 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
--
Wei Tan, Ph.D.
Computation Institute
the University of Chicago|Argonne National Laboratory
http://www.mcs.anl.gov/~wtan
------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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-12, 2009. Register now!
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
