Skip to content
This repository has been archived by the owner on Jul 9, 2022. It is now read-only.

Enhancing plugin with a possibility to detect relationship between generated artifacts and Eclipse Gradle projects #39

Closed
romix opened this issue May 28, 2014 · 6 comments

Comments

@romix
Copy link

romix commented May 28, 2014

I have the following setup:

  • N Gradle (root )projects A1..An, each imported in Eclipse as a separate project
  • Some of the Gradle projects are dependent on artifacts (JARs) produced by other projects (they depend on snapshot versions), e.g. A1 is dependent on the artifact A2-SNAPSHOT.jar produced by A2.

When I change sources in A2 and add e.g. a new method, I'd like to be able to directly use this new method in A1, i.e. with autocompletion, etc. But today it is not possible, because this change is invisible to Eclipse. One should first build and locally deploy the artifact produced by A2. And only then Eclipse detects the change in the JAR and is able to provide autocompletion and so on.

It would be nice, if Eclipse could detect this kind of changes automatically without requiring a dedicated build/local deploy step. It would be much more convenient and less error-prone.

Idea: I can imagine that this feature would work, if the Eclipse project for A1 would depend on the Eclipse project for A2 (and with current Gradle Plugin and Gradle tooling it always depends on the JAR produced by A2 and therefore changes are not detected automatically). So, a possible solution could be that Gradle plugin detects that a given JAR is produced by a given Eclipse Gradle project and adds the dependency on that project automatically in the Eclipse project configuration.

What do you think?

@BoykoAlex
Copy link
Contributor

Think it makes sense. Can you please submit a JIRA for this enhancement? (Would be nice if you could attach a sample project to the JIRA)

On May 28, 2014, at 5:17, romix notifications@github.com wrote:

I have the following setup:

N Gradle (root )projects A1..An, each imported in Eclipse as a separate project
Some of the Gradle projects are dependent on artifacts (JARs) produced by other projects (they depend on snapshot versions), e.g. A1 is dependent on the artifact A2-SNAPSHOT.jar produced by A2.
When I change sources in A2 and add e.g. a new method, I'd like to be able to directly use this new method in A1, i.e. with autocompletion, etc. But today it is not possible, because this change is invisible to Eclipse. One should first build and locally deploy the artifact produced by A2. And only then Eclipse detects the change in the JAR and is able to provide autocompletion and so on.

It would be nice, if Eclipse could detect this kind of changes automatically without requiring a dedicated build/local deploy step. It would be much more convenient and less error-prone.

Idea: I can imagine that this feature would work, if the Eclipse project for A1 would depend on the Eclipse project for A2 (and with current Gradle Plugin and Gradle tooling it always depends on the JAR produced by A2 and therefore changes are not detected automatically). So, a possible solution could be that Gradle plugin detects that a given JAR is produced by a given Eclipse Gradle project and adds the dependency on that project automatically in the Eclipse project configuration.

What do you think?


Reply to this email directly or view it on GitHub.

@thomasj003
Copy link

Just took the liberty to do that --> https://issuetracker.springsource.com/browse/STS-3837 as I would love to see that feature in place as well.

Note: romix and me don't know each other, just seem to have the same problems / ideas ;)

@romix
Copy link
Author

romix commented May 28, 2014

@thomasj003 Thanks a lot for submitting a JIRA issue for this enhancement! You saved my time.

@thomasj003
Copy link

You might want to vote on the issue to show that more people are interested :)

@romix
Copy link
Author

romix commented May 28, 2014

Done

@kdvolder
Copy link
Contributor

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

4 participants