I recently updated my buildship plugin. I have a legacy build that has 150 projects in the settings.gradle file and because of this - I have created a “pared-down.gradle” file with 10 projects in it. I used to be able to supply a -c pared-down.gradle to build ship but i cannot do this any more!
I’m hoping that I’ve somehow missed an option - has this capability been removed? (I’m hoping it’s just hidden)
This is indeed no longer supported. The reason was that it was mostly abused. Many projects could only be imported when the developer followed a bunch of instructions like “Now you need to set these properties”. We wanted to discourage this kind of setup, making users think about the developer experience first and making the CI server the special case.
Could you elaborate on the use case a little more? How do you decide what goes in the pared-down version? Do you normally only care about those 10 projects? Or do you decide on a day-to-day basis what you want to import?
I understand this opinion - but good gravy it really hampers people who don’t have the luxury of working on “shiny new projects”. Imagine all of the projects out there (like the one I’m working on) that have had years of ‘cruft’ slammed into them. Cruft that I don’t care about because this is a monolithic repository. There are “10 or so” core projects (which is already too many but 10 is reasonable) and there are 140 other ones that are busted for buildship because (unlike the STS plugin) buildship currently doens’t handle nested ‘ant-like’ project - like this one. i have 150 projects - of which i only care about a few of them and yet i need to ‘fix’ 140 other projects that i didn’t have to before. we have a lot of developers all in this monolith some use 10 projects, some use 20, some need all 150.
does that make sense? to prevent ‘crazy abuse’ i could see a field saying “override settings file” and one for “override build.gradle file” (-b) etc. this feels like a step back to me. 
Is this a decision that could be reconsidered? I don’t think the tool should impose it’s will on people in this way (even if I agree with you - and I do). I expect that it makes supporting the tool harder because people are doing “the wrong stuff” but maybe you could put this behind some “advanced options” screen with a warning?
Can you please elaborate on that? What does Buildship not support? Could you maybe create a small example on GitHub?
As for using a subset of projects, there are several ways to tackle that:
The last option is what you can use as a workaround for now. The second option sounds more like a correct modeling of this situation. I’d fight pretty hard to not bring back the first 
Honestly if I could make some simple examples I sure would. The nested project turned out to be a problem with 2.14.1 and BuldShip 2 (you helped me on that one - thank you). The feature I’m fighting with now (I am still trying to get it to work) is “eclipse.project.linkedResource”. I’m not a fan of this gradle setup but it’s the legacy beast I’m trying to tame…
I still don’t understand the aversion of bringing the old UI back (again - maybe hidden under an ‘advanced’ button view). The UI to pick/choose the projects is exactly how the STS plugin worked and was “ok” but really for those of us who like to think we “know better” it’s not as useful because I can’t use that on the command line. I am a big proponent of “what you do on the command line should work in your IDE” or “what you do in the IDE should be doable in the command line”
The last bullet point is a workaround but it’s not a particularly good one as it requires me to modify the existing settings.gradle file. That opens me up to checking it / pushing is by mistake.
(this is what I did and had to do though)
I don’t think the tool should try to force me down a path though - that’s a dangerous precedent to be setting in my opinion. If gradle supports it - so should buildship… warts (features?) and all.
It wouldn’t be a mistake, it would then be a clearly visible feature of your build: Developers can overwrite the projects to use.
The thing is, I believe that the two options to provide a custom build file or settings file shouldn’t even be there. There should be exactly one entry point into your build from which the curious developer can discover everything else. Adding that partial import support to your settings.gradle file is just an if-statement away:
if (file('partial-settings.gradle').exists()) {
apply from: 'partial-settings.gradle'
} else {
// include everything
}
Thanks for expanding the way I think about gradle. It didn’t even occur to me that settings.gradle is a gradle file and thus I can write things like if statements in there. I didn’t realize that was what you were saying until you provided your example. What would have been very helpful is to have something to search on or some doc that indicates “if you used to do this, then you now need to do it this other way” sort of guide. In my opinion - this answer is far more “clunky” than I would like because now i have to explain to people how to trigger this alternate behavior. I might not have set the stage so let me try again - maybe it might sway you.
I have 150 projects. From those 150, “core” developers building the engine so to speak care about 5 projects and no more. UI developers care about the same 5 core projects plus 10 extra (15 total). Then there are “plugin developers” they care about 5 + 10 + 100, and “extension developers” who care about the 5 core projects + 15 projects that aren’t “ui” or “plugin” projects. All of these developers can’t check in the settings file for that respective group using the if(file.exists) approach. Now what I can do is put down a marker file that is basically a property file which says “activate core”, “activate ui”, “activate plugin”, “activate extensions”. That will work so that’s the route i’ll go but I thought if I outlined the build more you might get a different vibe for the complexity of this legacy build.
I still fundamentally disagree with the position you (or all of the buildship devs) take with respect to the options. Developers want to do things they way they want to do them, by restricting a developer from shooting their own foot because the buildship team is encouraging the “right” behavior can very well lead to alienating the people that use the tool.
At the same time, I appreciate your work on this project. I do wish you’d all reconsider being dogmatic about enforcing “the right kind of setup” as you all see it and consider that other people might have differing opinions as to “the right kind of setup”. I still feel strongly that the buildship tool should not be trying to ‘fix gradle’ (so to speak). If gradle supports it - and if people use it, buildship should support it. I can make this work though now that I have an approach that would work.
Well how do they do it currently? My understanding so far was that every developer has their own “reduced settings file” which is ignored by SCM. Of course you could also check in a few well-known combinations and add a property that developers can set to say “I’m a UI dev” or something like that. That property could be set in the user home or possibly in an SCM-ignored properties file in the project directory.
The other nice thing about persisting your “choice of projects” either in your user home or in an SCM-ignored file in the project is that you don’t have to pass an argument to each CLI invocation.
We’re not trying to fix Gradle. But Gradle already provides enough hooks to do the kind of setup you are describing, so I don’t believe we need yet more locations where users put configuration for their projects. The build file and potential property files should be enough.
Just to give you some more perspective: We already had users asking to also provide workspace-wide arguments. And then the next request was to provide Eclipse property substitutions in those arguments. And yet another request was “Hey, sometimes I want to opt out of the project-wide settings I did, give me an option for that too”. It’s an endless rabbit hole. Funny enough, IntelliJ Idea never offered this option and no one seems to be missing it there. This is why I’m convinced that Gradle already provides enough customization mechanisms.
This probably also will not be considered a valid use case but here goes:
I use an organization specific Gradle init script that houses some shared setup including internal repositories. I was using the buildship plugin’s program arguments under advanced options to specify the init script. From the command line we are using a custom bash wrapper to automatically include the init.
I didn’t want to put the init script in the usual locations because it will always be picked up. In the event that a developer is working on an external project they shouldn’t be using the internal init script. This was working well until the advanced options disappeared. I’m not positive what the workaround will be other than to universally apply the init script by putting it in the user’s .gradle directory…
Company-wide init scripts can be put into a custom Gradle distribution. You just take a Gradle distro, put your script in the init.d directory and package it back up. Then you host that modified distro somewhere in your company and point your Gradle wrapper at it.
Alternatively, you can also do pretty much everything you can do in an init script inside a settings script, because you can just use Settings#getGradle(). So in your settings.gradle script you could use apply from: 'some-remote-url'. That’s even easier than the custom distribution.
Either of these options leads to a build that needs no additional IDE setup and no custom CLI scripts.
Which is exactly what we do, yeah!
Let me add that I would appreciate a volunteer who creates and publishes a sample project that allows to build a custom Gradle distribution (starting from the standard Gradle distribution); using Gradle, of course. (We are currently creating, packaging, and uploading our custom distribution manually, sigh.)
MrHaki already did that: http://mrhaki.blogspot.de/2012/10/gradle-goodness-distribute-custom.html
Thanks! Haven’t seen that yet.
I don’t mean to resuscitate this thread but I came across this thread while trying to solve a problem I’m currently having with the Buildship plugin. Hopefully this will help someone out though.
Here is an example of a custom distribution (inspired by that post by MrHaki) we created to solve the issue of accessing build plugins from private, password protected repositories: