On 20 Dec 2013, at 18:16, Xavier Ducrohet wrote:
Hello,
We have a user who had an issue with two different plugins that
depended on
different versions of ASM.
Is there a way to see the build script dependency graph (similar to
running
the dependencies task)?
Not currently, though this would be something that would be good to add.
It's a little more complex than the proper configurations to visualise,
but we could do something.
Can the dependency conflict resolution apply to the build script
classpath?
It does right now.
Is there any way to silo each plugin into their own separate
classpath?
This seems fragile right now.
Not right now, but it's coming.
A naive approach of simply completely isolating each plugin into its own
class loader doesn't work because then plugins can't collaborate. For
example, my plugin that builds on the Android plugin wouldn't have
access to the model classes from it because they'd be in a separate
class loader. To make this work we essentially have to provide our own
dependency based class loader visibility system like OSGi or
ClassWorlds, which we have started planning.
Before we get there though there are some things we need to do:
1. Allow plugin classpath to be derived at application time (right now
the opposite is the case)
2. Allow plugins to declare their public types
3. Allow published plugins to declare their public/private classpaths
There is more detail in this spec:
https://github.com/gradle/gradle/blob/master/design-docs/publishing-and-sharing-plugins.md
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
