You can do this today by:
buildscript {
configurations.classpath.resolutionStrategy.failOnVersionConflict()
}
When is it planned for?
It's something we are working on, but it's probably going to be at least
2 - 3 release cycles at best before it would effectively resolve this
kind of problem.
On 23 Dec 2013, at 20:23, Xavier Ducrohet wrote:
That makes sense. I'm glad to hear it's coming.
When is it planned for? If it's in a while, would it be possible to
make
resolution strict for plugin classpath (ie, consider the dependencies
to be
exactly the version they declare, and break on all conflict)? this
would
make figuring out conflict easier and would still allow for fixing
this
through the conflict resolution already in place.
Xav
On Sat, Dec 21, 2013 at 5:33 AM, Luke Daley
<luke.da...@gradleware.com>wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
