ProjectCreatedEvent alternatives

Help/Discuss Buildship
1

Hello buildship team,

I noticed that ProjectCreatedEvent class has been deleted. Our team (Liferay IDE plugin) was using that event in order to detect new gradle projects being synchronized in the workspace and configure some projects based on criteria we detect with tooling api.

Are there alternatives for buildship adopters to participate in the project configuration process?

2

FYI: added a new PR to re-add a simplified event to re-enable our use-case. thanks

3

Hey Gregory,

please note that as of now, Buildship has no public API.

If I understand your use case correctly, it could be solved another way:

  • have an IResourceChangeListener that listens for project creations
  • check for the Buildship nature
  • if present, do your customizations

Would that work for you?

Cheers,
Stefan

4

Thanks Stefan for your reply. And yes, it is true that I could use a IResourceChangeListener to listen for project creations. But such a listener would be called for every single change in the whole workspace, and creating delta visitors to filter through everything which 99.9% of the time is not going to be a “new project was created” event.

I was just hoping for a more direct way from buildship API to hook the “project creation/configuration” process (similar to how m2e has project configuration step). Eclipse is slow enough, it doesn’t need yet one more course-grained global resource change listener does it? :slight_smile: But on the other hand I understand buildship wanting to reduce their API exposure, because “never breaking API” is sometimes an albatross around Eclipse innovation.

5

I understand that you are in a somewhat uncomfortable situation, not being able to integrate at a more efficient level. We are definitely aware that we’ll need some kind of extensibility in the long run. But right now there are still too many changes to how synchronization works to expose that publicly. The biggest change will come with Buildship 1.1 and composite builds.

Once that has settled down, we will consider different extensibility options, either on the Gradle side or with extension points or even a combination of both. Details on your use case (what are your configuring, based on what information?) would help us make the right decision there :slight_smile:

6

Thanks Stefan for the details. We can move forward with resourceChangeListener. Is there a bugzilla entry for extensibility use-case? I can follow that accordingly.

7

Yes, there is an enhancement request for that.

8

Thanks I’m following.