Optionally keep custom natures and build commands

[mauromol]

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:

• many build commands are removed: org.eclipse.wst.jsdt.core.javascriptValidator, >org.springframework.ide.eclipse.core.springbuilder, org.zeroturnaround.eclipse.rebelXmlBuilder, org.eclipse.jpt.jpa.eclipselink.core.builder
• many natures are removed: org.springframework.ide.eclipse.core.springnature, org.eclipse.wst.common.project.facet.core.nature, org.eclipse.wst.jsdt.core.jsNature, org.zeroturnaround.eclipse.jrebelNature, org.eclipse.wst.common.modulecore.ModuleCoreNature (on a Utility project)

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).

[oehme]

This is intentional. Buildship treats the build as the source of truth. If you want to have extra builders/natures, you can use the eclipse.project {} DSL to add them. The added benefit is that you no longer need to check in handwritten .project/.classpath files.

Leaving builders/natures in the project even though they are not part of Gradle's model would result in inconsistently configured projects.

[mauromol]

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!
One thing is to control how the project is set up with regards to features related to the building of the project (i.e.: Java compiler compliance, source folders, classpath, dependency management, application server deployment etc.), but controlling which plugins I use in the IDE to edit my project source code is a whole other story!

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)?
So, I have to learn that (the current version of) JRebel needs a org.zeroturnaround.eclipse.rebelXmlBuilder builder and a org.zeroturnaround.eclipse.jrebelNature nature? That I need to use another builder and nature to use Spring IDE? That I need a certain builder to use Eclipse JPA Tooling to easily manage JPA Entities? and so on? And what about changes in plugin versions and implementations (which might replace builders and natures without advice)? Do I need to make reverse engineering of each IDE plugin version, search for documentation, apply changes by trial and error and diff against the source control system to find out what I should add to my build.gradle so that the resulting .project file is what it is intended to be?
And what about plugins that use a mixture of .project and other metadata files and that may be messed up from this kind of overwriting that Buildship performs? Should I also code the generation of all the other metadata files, in Groovy or what else??

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!

[davidecavestro]

@oehme the automatic bulldozing of existing configuration by a plugin is a bad move.

[AndyWu2015]

I agree with @davidecavestro and @mauromol , please consider not do this in buildship @oehme .

[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:

• manually added natures
• manually added builders

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.

[mauromol]

Very glad to see this reconsidered, thank you! 👍

[AndyWu2015]

glad to see that ! Hoping this issue would be done as soon as possible . :)

[berndwaibel]

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.
After that, IIB does not handle this projects as IIB projects, because the builders and natures are missing.

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.

[oehme]

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.
After that, IIB does not handle this projects as IIB projects, because the builders and natures are missing.

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 eclipse.project.natures 'natureName'). That's what e.g. the java and groovy plugins in Gradle do, they add the JDT/Groovy nature and builder respectively. Users should not have to fiddle around with the Eclipse UI or .project files to do that. Ideally all this logic should be encapsulated in an IIB Gradle plugin, if this is a tool that's used in many projects.

Gradle does not need to know about Eclipse plugins, it is buildship which needs to know that.

Gradle computes the Eclipse model, not Buildship. Buildship just takes that model and applies to the Eclipse project.

so I hope for a fast redesign of buildship accepting other eclipse plugins.

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.

[wodencafe]

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.
Also, this nature was added to the .project file automatically with the Kotlin-Eclipse plugin, there was no manual editing involved.

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?

[oehme]

Also, this nature was added to the .project file automatically with the Kotlin-Eclipse plugin, there was no manual editing involved.

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?

[wodencafe]

The Kotlin Gradle plugin should be adding this nature to the Gradle Eclipse model.

@oehme Good point.

[mauromol]

User shouldn't have to check in .project files.

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).

[wodencafe]

@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.

[oehme]

I said that user "shouldn't have to", not that they "must not".

[chasecaleb]

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?

[donat]

@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.

[chasecaleb]

Great, thanks for the explanation.

[mauromol]

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 ?

[donat]

@mauromol you are correct. I've adjusted the milestone and the label, so now this issue is listed under the enhancements.

[donat]

@chasecaleb I've renamed the was:delivered label to was:implemented to make it easier to understand.

[mauromol]

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.

[oehme]

Thank you @mauromol for your kind words and your patience and persistence.