Skip to content
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

Run tasks on synchronization #265

Closed
donat opened this issue Feb 4, 2017 · 22 comments

Comments

Projects
None yet
9 participants
@donat
Copy link
Contributor

commented Feb 4, 2017

Motivation

Some projects have setup tasks that need to be run before they can be used in the IDE. That might be a long-running code generator or some configuration task for an Eclipse plugin that Buildship has no model for.

This would be an inexpensive workaround for our missing WTP support. Instead of creating a full-blown tooling model for WTP, we could just run the wtpComponent and wtpFacets tasks.

Proposed Change

Add eclipse.synchronizationTasks to the Gradle Eclipse API, expose them via the TAPI and run them before the actual project synchronization.

@donat donat added the an:enhancement label Feb 4, 2017

@donat

This comment has been minimized.

Copy link
Contributor Author

commented Feb 4, 2017

Comment by oehme
Monday Aug 29, 2016 at 09:02 GMT


The WTP case can be implemented even simpler by hardcoding support as in #85 .

@donat donat added the from:bugzilla label Feb 8, 2017

@donat

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2017

@adammurdoch

This comment has been minimized.

Copy link

commented Feb 13, 2017

It would be nice if we solved this by offering a way to declare the developer inputs in a Gradle build definition, and simply make sure these things are built on import and then kept up-to-date as things change. This way, the inputs can be made usable regardless of which IDE the developer is using.

We might model these as 'buildable things' somewhere that you declare, or we might infer that generated source files or resources that are inputs into the main or test source sets should be built prior to use from the IDE.

@oehme

This comment has been minimized.

Copy link
Member

commented Feb 14, 2017

@adammurdoch this ticket is more about Eclipse-specific things that need to be generated when you "sync" the Eclipse configuration. This is really just a convenience for Gradle plugins that don't want to build a full-blown tooling model + Eclipse plugin, but just want to create some configuration file.

There is another ticket (#266) for what you are referring to: Tasks that need to be run in order to keep generated sources up-to-date. These should be IDE independent, but I don't think we're there yet: We want to replace the built-in generators/compilers in IDEs, but that requires us to provide the same rich diagnostics that IDEs currently provide (e.g. collecting all errors and warnings from all generators/compilers and putting them on the correct source files). Of course doing exactly that could be the solution for #266 instead of having an Eclipse-specific list of tasks.

@Kameecoding

This comment has been minimized.

Copy link

commented Feb 10, 2018

what's the status of this feature is it being worked on?

@ChristianCiach

This comment has been minimized.

Copy link

commented Jun 18, 2018

We need this to automatically trigger eclipseFactorypath and eclipstJdtApt of the APT-Plugin. There is no way that I convince all my colleagues to manually run these tasks every time the factory path changes.

@Gentleman1983

This comment has been minimized.

Copy link

commented Jun 21, 2018

Same here considering the eclipse and eclipse-wtp tasks.

@ybayk

This comment has been minimized.

Copy link

commented Jul 19, 2018

This feature indeed would be very useful for generated sources. Currently we have to instruct developers that Gradle import/refresh is not sufficient, and one extra task has to be executed from command line.

@stefanleh

This comment has been minimized.

Copy link

commented Nov 27, 2018

Same here. We got a very prehistoric way of copying libs from a central webshare to the lib folder of the project for updating dependencies when in a sealed environment (no Nexus in network / no Internet at all). This should be triggered via Gradle task when "Gradle refresh project" is run.

@ChristianCiach

This comment has been minimized.

Copy link

commented Dec 13, 2018

Sad to see that this feature didn't make it for Buildship 3.0. Unfortunately, Buildship is unusable for our company as long as the workspace is in a broken state after synchronization before additional tasks are run. Why no love for annotation processors?

@donat donat added this to the Buildship 3.2 milestone Dec 17, 2018

@donat

This comment has been minimized.

Copy link
Contributor Author

commented Dec 17, 2018

@ChristianCiach We didn't implement this for Buildship 3.0 as the release already contained way too many changes. The feature list might not seem too long but internally we did major refactorings.

FYI we have a rough plan what comes next. In 3.1 we're going to fix #829, then we'll implement this issue.

donat added a commit to gradle/gradle that referenced this issue Mar 22, 2019

Run tasks upon Eclipse synchronization
This commit implements the Gradle side of the 'Run tasks upon synchronization'
story for Buildship:

eclipse/buildship#265

It contributes a new `eclipse.synchronizationTasks` configuration. By using the
phased build action API, clients can execute the configured tasks and load the
Eclipse model in one step. Also, the task information never needs to leave the
Gradle process.

donat added a commit to gradle/gradle that referenced this issue Mar 22, 2019

Run tasks upon Eclipse synchronization
This commit implements the Gradle side of the 'Run tasks upon synchronization'
story for Buildship:

eclipse/buildship#265

It contributes a new `eclipse.synchronizationTasks` configuration. By using the
phased build action API, clients can execute the configured tasks and load the
Eclipse model in one step. Also, the task information never needs to leave the
Gradle process.
@donat

This comment has been minimized.

Copy link
Contributor Author

commented Mar 22, 2019

The Gradle-side implementation for this story is ready. I'll merge it next week.

donat added a commit to gradle/gradle that referenced this issue Mar 25, 2019

Run tasks upon Eclipse synchronization
This commit implements the Gradle side of the 'Run tasks upon synchronization'
story for Buildship:

eclipse/buildship#265

It contributes a new `eclipse.synchronizationTasks` configuration. By using the
phased build action API, clients can execute the configured tasks and load the
Eclipse model in one step. Also, the task information never needs to leave the
Gradle process.

@donat donat self-assigned this Apr 12, 2019

@donat donat closed this Apr 12, 2019

@lukeu

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

Great stuff! If I wanted to take this for an early spin: will I need to build buildship from source, or is there an update-site URL I can use?

Regarding how eclipse.synchronizationTasks works: so I should simply list names of gradle task(s)?

eclipse.synchronizationTasks = [ 'generateWhatEclipseDoesnt' ]

#266 talks about performing actions upon build, but I don't see a different trigger for that? For example, we also have a little task to encrypt a resource file, which can be edited quite frequently when working in that area. It would be great if that could just happen on a build (Ctrl+B, or more specifically: right-click the specific eclipse Project, Build) which usually takes a split-second, rather than [Gradle -> Refresh] which can take 30s or so even for a no-change refresh.

@donat

This comment has been minimized.

Copy link
Contributor Author

commented Apr 15, 2019

@lukeu answers below:

will I need to build buildship from source, or is there an update-site URL I can use?

No, you'll only need the latest snapshot and Gradle 5.4-rc-1. We have some difficulties ATM as the Eclipse servers disabled our account, but once that's fixed I'll kick of a snapshot build. I'll let you know here when you can proceed.

Regarding how eclipse.synchronizationTasks works: so I should simply list names of gradle task(s)?

Yes, that should work.

It would be great if that could just happen on a build

That's precisely how the eclipse.autoBuildTasks works.

@lukeu

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

That's precisely how the eclipse.autoBuildTasks works.

Super! I saw that mentioned in earlier discussions but didn't realise it was also done.

@donat

This comment has been minimized.

Copy link
Contributor Author

commented Apr 15, 2019

The snapshot release is out, you can give it a go.

@donat donat modified the milestones: Buildship 3.2, Buildship 3.1 Apr 23, 2019

@donat

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2019

A quick heads-up. We scheduled the release review to 1st May, and the release will follow shortly. Early adopters can evaluate the new feature with the latest snapshot or milestone.

@ChristianCiach

This comment has been minimized.

Copy link

commented Apr 25, 2019

Just to avoid confusion: eclipse.synchronizationTasks = [ 'generateWhatEclipseDoesnt' ] is not the correct syntax. synchronizationTasks is not a property.

Following the api documentation, this should work:

eclipse.synchronizationTasks eclipseFactorypath, eclipseJdtApt, eclipseJdt
@lukeu

This comment has been minimized.

Copy link
Contributor

commented May 6, 2019

Early adopters can evaluate the new feature with the latest snapshot or milestone.

Thanks! Here's my feedback:

synchronizationTasks so far is working very nicely :-)

With autoBuildTasks I encountered two issues:

  1. It only seems to do anything while [Project > Build Automatically] is enabled. I see that is explicit in the naming... :-) However I do not think it is useful for this feature to distinguish between the types of action that initiated a project-build, rather it should execute consistently whenever a project is built regardless of the action that triggered that.
  2. My intended use-case involves post-processing some resource files, and the result ends up being out-of-date. Specifically if I...
  • edit the original resource,
  • save (to auto build it)
  • wait (for any auto-refresh resources to complete)
  • launch my application

Then I see the result corresponding to the build one prior. Now it is probably the case that I need to rework the (re)source directory structure or something to fix this. However I didn't play with it too much since (1.) is already a blocker. And as a workaround I can just put this in synchronizationTasks, which seems to build robustly without other build-script changes.

Suggestion: Could the documentation say a bit more about at which point the autoBuildTasks step will occur in the sequence of operations that Eclipse performs? The wording "during the Eclipse auto-build" is rather vague.

@donat

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2019

@lukeu I think the auto-builder task is correct regarding it only triggers when the Project > Build Automatically is enabled. I wouldn't want to see expensive calculations in my IDE if I explicitly disabled that. I can still see it happening, just in a different hook (i.e a separate eclipse.resourceChangeTasks).

I completely agree though, the autoBuildTasks would need more description. Actually, the implementation is quite straightforward, we call the tasks in the Gradle project builder. I've created a new issue to add more documentation.

@ChristianCiach

This comment has been minimized.

Copy link

commented May 15, 2019

Just an idea: Eclipse has the concept of "Save actions" (you can search the preferences for this). I think it would be great to be able to configure the Gradle tasks to run at the "save action" configuration dialog.

For example, I would like to use an external code formatter, so that developers can use the IDE of their choice. I think a "Save action" would be the perfect place to trigger the corresponding Gradle task, because Eclipse's own code formatter can be triggered this way, too.

Edit: I don't know if "save actions" are triggered before or after the files were actually written to disk. Of course, this whole idea is void if save actions can only be executed before the files are written to disk.

@lukeu

This comment has been minimized.

Copy link
Contributor

commented May 16, 2019

Hi @donat,

I think the auto-builder task is correct regarding it only triggers when the Project > Build Automatically is enabled. I wouldn't want to see expensive calculations in my IDE if I explicitly disabled that.

Well maybe that is based on a particular mode of operation? Eclipse has a range of preferences - for example "auto-save upon (presumably a manual) build" sounds like the opposite way around to Tools > build automatically. (Not that I use that myself)

I don't like expensive operations running repeatedly in the background, and prefer to be in control over them. So I do these 3 steps manually: (1) refresh Gradle, (2) Ctrl+(Shift+)S to save all, (3) Ctrl+B to build. Importantly, the last one swaps the updated code into a running debug session, so I definitely want to be in control of that. I can avoid applying changes I know would break what I'm testing. (But maybe I want to save & commit to git anyway.)

So this seems to be leading to wanting potentially 3 save/build triggers:

  1. Run tasks with auto-builds
  2. Run tasks on manual-build
  3. Run tasks when resource is saved (which I infer is what eclipse.resourceChangeTasks was suggesting?)

But personally I see as a mistake to split 1 and 2. Why would we want an explicit build command (Ctrl+B) to only do a partial build? Where the only way to get the code into the completely-built state is to turn Auto Build on (and then off again)? I don't think the design should let the user get into that confusing "partially-built" state at all.

Anyway, there be ways to avoid "expensive calculations" upon build though, right?

  • don't run the expensive tasks then (maybe move them to do during a sync?)
  • keep using auto-build
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.