I’d like to have a task that launches an external “launchServer” process available from the main project and all subprojects via a plugin. Unfortunately, if I launch my “launchServer” task from the root, it launches it for root + one instance per subproject. How do I get “singleton” behavior?
It’s hard to answer this question with the information provided. In general, you get “singleton” behavior by adding just one task, e.g. to the root project. Or you execute just the task in the root project with “gradle :launchServer”. Or you add the task just to the children, but not to the root project. (If necessary, you can add another child instead.)
thanks for the answer. your gradle :launchServer does work. However, it’s not really what I’m looking for. We will soon have hundreds of developers using gradle and I don’t want them to have to know to type a “:” in front of their task when they are at a subproject. And it doesn’t show in the task list for the subproject anyway, so they won’t discover it.
I tend to hang out at the root level myself, but many spend most of their time at the subproject level. I am looking for having the convenience of having a consistent command across all these cases.
sounds like there isn’t a good way to do this…
This is an interesting use case. We have been discussing pros and cons of the name matching execution pattern very often. An alternative implementation Gradle could do, is to have a pattern that is strictly task and task dependency based. The parent project would have dynamic aggregate tasks that correspond to the subproject tasks. The behavior would be mostly the same to the current. But in scenarios like yours you could modify the dependencies so that the parent project task would no longer aggregate.
One thing you could do right now, is to have the actual launchServer task defined in your root project. In your subprojects you could have launchServer tasks that dependOn ':launchServer". That way you can execute launchServer from everywhere with the desired behavior. The console output is quite verbose though if you execute it from root and might be confusing.
thanks for the workaround suggestion.
Is this something I should enter in Jira as a feature request (singleton task)?
I agree that we need a more flexible solution than the current name matching execution pattern. In particular, the current solution doesn’t allow for a task that can be executed for each project individually but has true aggregating behavior when executed for a non-leaf project. This is often a desired behavior for reporting plugins.
One improvement that comes to mind is to look for matching tasks starting from the top of the project hierarchy, and when a matching task is found, decide based on a standard task property whether to continue the search further down the hierarchy or not. This would neatly solve the aggregation problem.
this is a test (http://www.dzone.com/links/r/dive_into_html5_is_back_online.html).
Phil, please do create a JIRA for this. It’s something we should track.