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

Multi-project, multi-module does not work in Eclipse #708

Closed
vittali opened this issue Jun 1, 2018 · 22 comments

Comments

@vittali
Copy link

commented Jun 1, 2018

The tutorial project does not compile in Eclipse. Various workarounds have been suggested ( issues #620, #658, for example) non of them allows the tutorial to compile cleanly in Eclipse ( although the tutorial compiles and runs as expected on the command line), in particular the tests won't compile. I think the problem is related to how gradle manages the classpath/modulepath seen by Eclipse.

The bottom line: currently, the combination Eclipse Oxygen.3a Release (4.7.3a), Buildship 2.2.1, Gradle 4.7 and Java 10.0.1 seems to be unusable to develop java modules.

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

Closing as a duplicate of #658. Gradle's eclipse plugin is currently completely unaware of any Java module system specifics and is therefor not expected to work for modular projects.

@oehme oehme closed this Jun 1, 2018

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

So what do people do if they want to use gradle + eclipse to develop java modules ? Isn't this a widespread requirement ?
Is there a workaround ? Is there a roadmap ? Another IDE ?

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

We only got a handful of requests for supporting modules in general, so it hasn't been a widespread requirement until now. I expect this to change with Java 11 coming up, so we'll probably come up with a roadmap in the second half of the year.

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

While I understand and accept that this is currently not a prioritiy, I still struggle to understand:

  • why this is related to Java 11,
  • more importantly, why publish (1) an excellent guide on how to use modules, and (2) an experimental plugin ( that works fine for me) without taking the additional (3) step to allow people to really use this guide and this plugin (or the workarounds from the guide) in their work. Because without IDE support, I do not see how (1), (2) could be useful for people who uses IDEs.

Please don't get me wrong: I understand and accept what you say, but depending on how much work this missing (3) element ( Eclipse/IDE support ) requires, maybe you could consider giving it a higher priority, or at least make it visible on the roadmap earlier, given that a lot of very helpful elements are already in place.

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

I mentioned Java 11, because that'll be the end for Java 8, the last long term maintenance release before the module system was introduced.

I personally haven't tried this out in Eclipse, but I would have assumed that it would work, just not showing you module-system related problems. It should compile and run as if it was a classpath-based project. I know this isn't great, but you shouldn't be blocked from editing in the IDE.

So my basic question is: When you just import the example project as-is, what problems does Eclipse show you?

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

These are steps:

$  git clone https://github.com/gradle-guides/building-java-9-modules.git
$ cd building-java-9-modules/src/2-all-modules
$ sdk current java
Using java version 10.0.1-oracle
$ ./gradlew check
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine java version from '10.0.1'.
$ gradle wrapper
$ ./gradlew check
BUILD SUCCESSFUL ...
$ ./gradlew run 
-> OK: output shown in the guide

In Eclipse, I import the gradle project. See shot:
708-1

I now have lots of compile errors:

708-2

In particular, the only project that compiles is tale because it neither requires nor has it test code.

The storyteller project apparantly has no code on the buildpath:

708-3

I believe to understand at least some of these errors. As others have already noted, the module path doesn't contain any modules and the external dependencies remain on the classpath (and are therefore unnamed modules on which named modules can not depend):

708-4

708-5

A partial fix is to move the entries from the classpath to the modulepath:

708-6

now, the requires guava compiles.

But this will be reverted as soon as I refresh the gradle project and it does nothing for the compile errors in the test code.

Am I missing something really simple+stupid ?

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

Okay let me try to understand: Just because you added a module descriptor, Eclipse insists on treating your project as a modular project? That sounds like the underlying problem. There should be a way to opt out of this, be it just for backwards compatibility reasons. I.e. a lot of projects add a module descriptor to their project without actually running all their tests in a module environment. They are just slowly migrating.

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

I didn't add anything !
As shown, I imported the tutorial project exactly as you published it on github.
The module descriptor is already in the completed step 2 2-all-modules.

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

I didn't say you personally added anything. I'm saying that this project is a plain old Java project, but Eclipse insists on treating it as a module despite it not being fully configured as such.

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

Just imported the same project in IDEA and everything works fine. So this is Eclipse being overly picky about its configuration. IDEA does not distinguish between module path and classpath in the UI, it seems to figure out a good configuration itself under the hood.

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

Stefan, I am sorry, I didn't mean to be offensive, I just wanted to be sure that we start from a common baseline.

Independent of technical reasons, from my perspective as a gradle user, I see three possible cases:

  1. I am missing something very obivous
  2. The mentioned tutorial doesn't work for whatever reason for Eclipse users, but there is a simple workaround
  3. The mentioned tutorial doesn't work for whatever reason for Eclipse users, and there is no simple workaround

Case 3) means that I will have to wait, and given that all other Eclipse users that want java modules with gradle will also have to wait, I believe that some more visibility would be appreciated by a sizeable part of the community, even if as of right now, these requests are muted.

So to exclude case 1) and case 2), would it possible for you to repeat the steps I outlined and see what you find ?

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

See my previous answer, Eclipse is being overly picky here, IDEA handles this without a hitch. So yes, there is no simple workaround and I'll have to recommend using IDEA until we find some way to fix this.

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

Thank you, that's good to know (albeit unpleasant), maybe it would be useful to mention this in the guide as well ?

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

Yes, this wasn't tested when we wrote the guide, as our whole team is on IDEA. Would you be interested in sending a small PR to the guide repository?

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

Yes, and since I haven't done this before, please bear with me. Is this what I need to do ?

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

Yep, that's right 👍

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

I opened a pull request but forgot to sign-off. The way to fix this seems to be explained here, but the relevant link is dead.

@oehme

This comment has been minimized.

Copy link
Member

commented Jun 1, 2018

I've fixed the link.

@vittali

This comment has been minimized.

Copy link
Author

commented Jun 1, 2018

$ git commit contents/index.adoc --amend --signoff 
$ git push --force origin eclipse-708

Hopefully, this is correct ...

@calvertdw

This comment has been minimized.

Copy link

commented Feb 21, 2019

our whole team is on IDEA

I am frequently upset by this and I'm worried that it makes Gradle frail as a build tool. I'm a DevOps engineer for a team of ~20 Java developers and about half of them use Eclipse. And I like that, because as we all know, diversity and competition in software is a really good thing.

@polaroidkidd

This comment has been minimized.

Copy link

commented Feb 27, 2019

I am frequently upset by this

I am currently migrating a ant project to Gradle. The Project was initially composed of 8 super-projects and a total of ~150 Sub-Projects. The move to Gradle itself wasn't as difficult as anticipated. However, getting Eclipse 4.8.2 to work with 150 Gradle Projects is neigh impossible. I've tried using the Buildship plugin (import gradle project) as well as generating the eclipse project files by running the gradle eclipse task. The latter takes roughly 10 minutes (which is acceptable because it only runs once). However, opening the project in Eclipse is difficult (to put it mildly) as Eclipse resolves files for various gradle tasks (mainly classPath tasks). I have let it run through the night and it has completed roughly half of the 150 projects. Importing via the Buildship plugin results in the same tasks being run.

IDEA on the other hand can import the project, recognize inter-project dependencies and resolve all the files in aprox. 1 hour.

Even the team building plugins for Eclipse isn't using Eclipse. To me, there can't really be a more prominent indicator of a poor tool being switched for a better alternative.

@oehme

This comment has been minimized.

Copy link
Member

commented Feb 27, 2019

Importing a 150 module project should take well under a minute with Buildship. We have a 500 module example build with 5 million lines of code that imports in under a minute. So there's definitely something wrong in your project setup. It's hard to tell what without seeing an example though.

Even the team building plugins for Eclipse isn't using Eclipse.

@calvertdw Of course the team building Buildship uses Eclipse. I'm talking about the rest of the Gradle team. Module support is simply not among the things that most users ask for, so we haven't prioritized it. This is not even Buildship specific, it's something that we haven't prioritized for Gradle in general.

@polaroidkidd Locking this issue since it's geting off topic. If you'd like to investigate your performance issue with us, please open a new one and give us more information about it, ideally an example project that shows the import performance issues.

@eclipse eclipse locked as off topic and limited conversation to collaborators Feb 27, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.