When using ‘ProjectBuilder’ to dynamically create a project, I’m greeted with the cryptic error ‘Cannot increment beyond the total of: 10’.
‘ProjectBuilder’ is ment for test fixtures, but I figured I could use it to create a real project on the fly as that is what I need… I’m doing this in order to remove a distinction between 2 an android app project and a test project for it. The user should as much as possible think of them as 1 project.
Exact use case: Android plugin doesn’t allow applying the groovy plugin even for testing and thus you must create a separate separate project to be able to use robolectric + spock.
But I want the users of my plugin to be able to apply the plugin to the android project and put their test classes in ‘androidProject/src/test/groovy/’ and then have a project made on the fly for them that uses those classes as its sourceDir.
Essentially I want to hide the fact that the test project and the android project are separate projects, because they shouldn’t be.
Using ‘ProjectBuilder’ is not going to work here. Project returned by ‘ProjectBuilder’ are just dummy instances intended to be used for testing and not to build anything real.
It’s not possible to dynamically add projects to a build in configuration phase (this is what you are trying to do) - all projects have to be specified during initialization phase of the build (in ‘settings.gradle’) and at that time you won’t be able to detect if a project has some spock tests and add an additional one.
It feels to me that you are going to great lengths for very little gain. Can you please explain what do you find so wrong about having a separate project for tests in this case?
Yeah I know about ‘ProjectBuilder’ existing for the purpose of test fixtures, but I was thinking: what the heck…
Hmmh, why not? Is there any technical problem in the way of being able to add projects in configuration phase? The model of all projects isn’t finalized before ‘projectsEvaluated’ as far as I understand anyways… It worked fine in gradle 2.1 to use ‘ProjectBuilder’… and the ‘Cannot increment beyond the total of: 10’ comes from ‘SimpleProgressFormatter’, i.e: a logger… So evidently it is technically possible, and probably not that diffcult to implement.
I find it wrong because then you are no longer able to use the ‘src/main, src/test’ convention that normal projects use. It’s an ugly limitation that the android plugin puts on you that I’d like to get rid of…
There is no technical problem, it’s just that this is the way Gradle is architectured. It would be hard to keep things consistent if you allowed new projects popping up while you configure other ones. You have to know the set of projects upfront to be able to make certain decisions in the configuration phase.
Yes, the model of a project can be changed up to the end of the configuration phase but model contents and its existence are two separate concerns in Gradle.
The fact that it worked up to 2.1 was accidental - you were using it in an unsupported way thus it broke. This is the same as with using internal APIs - we don’t guarantee that things will keep working between versions if you do that.
As you said, using ‘src/test’ is a convention and conventions are not requirements and can be changed if there is a good reason. I think that you might want to raise your concern with Android plugin folks instead of trying to find a hacky workarounds.