Any plans on adding more classpath / dependencies configurability for tasks / plugins?

Old Forum
1

Hi. Are there any plans to allow the following: 1. be able to define additional classpath per task, as opposed to the whole project 2. be able to define additional classpath / dependencies per plugin? jetty plugin comes to mind, as it uses a fixed jetty version (6.x currently)

Maven allows classpath per plugin (which roughly corresponds to task in gradle) - do you plan on something similar? If not, what would be the way to, say, upgrade the jetty plugin to use another jetty instance, apart from messing around with gradle distribution (which is a hack, and not really usable with gradle wrapper, which I love).

What would be the way for multiple plugins to use some library in different versions? I guess a plugin would need to define a custom configuration and use just it, but this seems a workaround as well.

wujek

2

We’ll likely revise our class loading approach at some point, but no concrete decisions have been made as to how to improve over what we have today.

3

Just checking if there is any update in this area? Separate classpath/configurations per plugin is our immediate question. We publish all our plugins via a single project to a single JAR. And thus the dependencies for all plugins are mixed into a single set of compile/runtime configurations. I suppose we could break each plugin out into a separate project but that seems like a lot of trouble.

4

I’m not aware of any improvements in this area. If you need more fine-grained control over plugin class paths, I’d split them up into multiple Jars.

5

HI. What does the situation look like now? Or is it a feature nobody needs? I must say I gave a presentation on Gradle at my company and the modularity issues (fixed jetty, not being able to specify its version, no classpaths per plugin, …) were discussed a lot and the consensus seemed to be that it isn’t on par with the rest of Gradle.