-
Notifications
You must be signed in to change notification settings - Fork 168
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optionally keep custom natures and build commands #392
Comments
This is intentional. Buildship treats the build as the source of truth. If you want to have extra builders/natures, you can use the Leaving builders/natures in the project even though they are not part of Gradle's model would result in inconsistently configured projects. |
No, really, please reconsider this, otherwise I must really reconsider myself the use of Gradle in our projects!!!!! We use Gradle to control our build, we have no intention at all to use to control our tooling! So, you are saying I must now learn the internal of ALL the Eclipse plugins I'm using to work on my project in order to know which builders and natures I have to add in the build.gradle script so that I can CODE in my build.gradle all the things that my IDE would give me out of the box with just a few clicks (and in a controlled way)? Really, this is nonsense. No offence, but I think you're really missing the point with this "source of truth" thing. At least, please, give an option to opt out from this and let the user use Gradle + Buildship just to control the build process of the project, not the tooling I'm using in the IDE! |
@oehme the automatic bulldozing of existing configuration by a plugin is a bad move. |
I agree with @davidecavestro and @mauromol , please consider not do this in buildship @oehme . |
Reopening as per discussion on https://discuss.gradle.org/t/custom-nature-override-by-buildship-2-0-2/22515/16. The proposed solution would only include support for:
Users can tell Buildship on project import whether it should "fully own" these or whether it should leave user-defined entries untouched. All other configuration (e.g. classpath) will stay fully under Buildship's control. The rationale behind this is that there are quite a few plugins that are "decorative" in nature, i.e. adding some extra validation or content assist, but being otherwise unrelated to the correctness of the build. Users often reconfigure these plugins a lot or might only apply them in some cases, while the rest of their team doesn't use them. Having to change the build script for these convenience plugins can be cumbersome. |
Very glad to see this reconsidered, thank you! 👍 |
glad to see that ! Hoping this issue would be done as soon as possible . :) |
We are using IBM IIB (which is a tool used in large companies). When we import projects with Buildship (Import existing Gradle Project), and the project is a gradle AND an IIB project (which is indeed possible as by design in Eclipse, and works for all other natures and builder, except buildship) then Buildship (not gradle) removes (!) all existing natures and builder from .projects file. Eclipse is able of handling different natures and builders. I did not understand where buildship is not able to handle this, and why this should "break the build". And using a "build.gradle" is a one-and-only solution for buildship. Gradle does not need to know about Eclipse plugins, it is buildship which needs to know that. And all other eclipse plugins need to start reading the "build.gradle"? Really? No. For me, this sound like buildship keeps the position of "we are the king", ignoring completely the intention of natures and builders inside eclipse. Completely ignoring the design of eclipse. The fact, that "some people in the team does not use them", as stated above, is nothing buildship should have a opinion about, or should get hands on. And by the way, buildship does NOT do the build. This is gradle doing this. The sentence "The rationale behind this is that there are quite a few plugins that are "decorative" in nature, i.e. adding some extra validation or content assist, but being otherwise unrelated to the correctness of the build." is, sorry for that, easy minded. Yes, they may or may not have anything to do with the build. Correct, so leave them alone, because you do not know. Even if the plugins are "decorative", buildship should not even take care about this. As soon as you know all (!) plugins in the eclipse world, you are allowed to make assumptions about these plugins. Sorry, this makes me very angry, since I am using Eclipse for a long time. A plugin, which is not able to get along with other plugins, why should we use it? Really disappointed. Started so nice, but failed. We currently need to recommend to our customers not to use buildship, instead just use Gradle standalone. Gradle does not need the .projects file, so other plugins run fine. We will need to call gradle from command line or from jenkins, but this is fine. Developers for the build process will currently tend to switch to IntelliJ, which does have a good groovy and gradle support. But this is only needed for the build-developers, not the application function develobers. I would like to see buildship running again in Eclipse, but would be very difficult to switch back from IntelliJ, so I hope for a fast redesign of buildship accepting other eclipse plugins. Matter of time, I think. |
The idea is that your build should know that you are using IIB (I'm sure it is something that's used in your code, has dependencies etc - something your build needs to know about). So the IIB nature should be automatically added by Gradle (via
Gradle computes the Eclipse model, not Buildship. Buildship just takes that model and applies to the Eclipse project.
Buildship assumes that your build properly defines what tools you are using, so it can set up the IDE for the user. That's the job of the build author. If it is lacking that information, then that will result in odd behavior. We will add the ability for custom natures/builders back, but only with the intention to support @mauromol's use case of 'decorative' plugins. Natures/builders that are important for the basic function of your project should be declared in the build, so that every user gets a working IDE without editing .project/.classpath files. |
Thank you guys for reconsidering this issue, as I am using the eclipse DSL and Buildship is still removing the Kotlin nature from my Eclipse project. Could you maybe add some kind of setting or ability to turn this off, or define the behavior when dealing with unknown natures or regenerating the .project file? |
The Kotlin Gradle plugin should be adding this nature to the Gradle Eclipse model. User shouldn't have to check in .project files. Could you please fix that @Alexey-Tsvetkov? |
@oehme Good point. |
As I said in other contexts, this is debatable. This is your way to use Eclipse, but not the one of everyone else. Our use path is: check out the project (including the .project file) in a folder of your choice, then do "Import Existing Project into Workspace". After all, the project is already perfectly configured, no need to set it up from scratch using the Buildship "Import Gradle Project" wizard to rebuild project configuration files every time you check it out. And I'm convinced that other long standing sharing techniques in Eclipse that involve Team Sets and "Import from SVN" or alike are based on the same principle (i.e.: the existence of the .project file in the SCM). |
@mauromol Right, traditionally, before Gradle / Buildship existed, the .project & .classpath files have been included with the project when sharing with Source Control, so other team members' Eclipses understand the structure of the project. I understand the appeal of Gradle generating the .project file, but it becomes an issue when things don't work in the "ideal" way, like with the kotlin-gradle plugin, and then the .project file has to be manually configured within the Eclipse Gradle DSL, which wouldn't even be necessary if the .project file wasn't purged upon refreshing the project. So, I see the benefit of providing this new way of configuring the project and IDE settings, but requiring it to be done this way only works in a perfect world. |
I said that user "shouldn't have to", not that they "must not". |
This is closed and labeled delivered, but it doesn't appear to be in the current Marketplace release (2.0.2.v20170420-0909). What is considered delivered? |
@chasecaleb We add the 'delivered' label when we consider the feature implementation complete and merge it to the master branch. This feature is available in the latest 2.1.0 snapshots/milestones. We'll do the release once the Eclipse release review is complete and no blocker problems reported. |
Great, thanks for the explanation. |
Please note though that this issue isn't shown in either "bug fixes", "enhancements" or "new features" links for 2.1 milestone version at https://projects.eclipse.org/projects/tools.buildship/releases/2.1.0/plan ? |
@mauromol you are correct. I've adjusted the milestone and the label, so now this issue is listed under the enhancements. |
@chasecaleb I've renamed the |
At last I could test this with Buildhsip 2.1.1 on Oxygen. Let me say that now it's much more fun to use Buildship with my Eclipse Java and WTP projects, so thank you very much for your good work on this! I just have to add that a very similar problem is the one I described with #544, which however refers to WTP component file generation and update. |
Thank you @mauromol for your kind words and your patience and persistence. |
When using Buildship 2.0.0 to refresh a Faceted project, while NOT applying eclipse-wtp plugin (because, right now, due to the issues I encountered with Gradle-WTP integration I want to go on configuring WTP projects by myself), I get my .project files broken. What I see is that:
This happens whenever I issue a "Refresh Gradle project" and completely breaks our projects and forces us to downgrade to Buildship 1.0.21. I suspect some of these changes are affecting also non-WTP projects (for instance, it's removing the Spring nature and the JPA nature, as well as the JRebel nature, which are not related to WTP webapps).
The text was updated successfully, but these errors were encountered: