apache / lucene

Apache Lucene open-source search software
https://lucene.apache.org/
Apache License 2.0
2.64k stars 1.02k forks source link

Add gradle workflow support for Eclipse IDE [LUCENE-9438] #10478

Closed asfimport closed 4 years ago

asfimport commented 4 years ago

Off the top of my head I've tried using the eclipse plugin (this should prepare "static" classpath entries pointing at local gradle caches). It almost works... almost because we have references between sub-atomic project elements (tests and main) that make Eclipse see these as circular (because Eclipse treats project sources and main classes as one).

I pushed this code to jira/LUCENE-9438. Perhaps there are ways of making it work. I'm not a big fan of having a single "blob" project with all the sources and classpaths combined (the IDE won't help you figure out what's accessible from a given subproject then) but maybe it's the only way to make it work for Eclipse, don't know.

capture-1.png


Migrated from LUCENE-9438 by Dawid Weiss (@dweiss), resolved Aug 21 2020 Parent: #10119 Attachments: capture-1.png Pull requests: https://github.com/apache/lucene-solr/pull/1761

asfimport commented 4 years ago

Robert Muir (@rmuir) (migrated from JIRA)

The single "blob" project isnt a fanboy thing, I don't think anyone "likes" it: it is just a practical thing so that this IDE really works and doesn't choke all the time. As Uwe Schindler mentioned, it is a hack, but it works. A big important thing is keeping the eclipse memory reasonable so you can actually use it and it doesn't OOM. Because when it crashes you tend to lose work, which is really frustrating.

Even with just a single blob project and keeping things minimal, you constantly have to be your own "garbage collector" and be sure to not have too many projects open at once. I always make sure to close unused ones, otherwise it slows down too much and I know it will only crash and cause lost work.

Personally, I use it the same way as Uwe does: as a fancy autocomplete editor (because java is an extremely verbose language). For any other programming language I really just use vim, but for java it is just too painful to e.g. type in every import statement manually or rename things :) Running build and tests, git operations, etc: I do all this stuff from the commandline. From Uwe's comments, I think he uses a similar strategy.

asfimport commented 4 years ago

Dawid Weiss (@dweiss) (migrated from JIRA)

That was my point: autocomplete in such a setup doesn't really work as it'll suggest things that shouldn't be visible on a given subproject's classpath. Also, I know Eclipse can be a pain with multi-project workspaces - this was one of the key reasons I moved from Eclipse to IntelliJ, actually.

asfimport commented 4 years ago

Robert Muir (@rmuir) (migrated from JIRA)

gradle cant solve these issues though... and intellij isnt an option for me. no offense but i have been thru this battle over and over with maven, gradle before. and each time they think that their build tool will fix it but they dont understand it is just .project and .classpath and stuff and their new fancy build tool is not relevant.

i will try to set aside some time to make an eclipse target here.

asfimport commented 4 years ago

Dawid Weiss (@dweiss) (migrated from JIRA)

I really am IDE-agnostic, I don't care. I use what works, including vi.

Generating global .classpath should be relatively easy; snippets that may be helpful here:

Collect sourcesets from all java projects:

            if (project.plugins.findPlugin(JavaPlugin)) {
                [
                    project.sourceSets.main.java.srcDirs,
                    project.sourceSets.test.java.srcDirs,
                ].flatten().each { srcLocation ->

Source folders should have per-location outputs (in case the same class is duplicated in multiple source locations).

To collect (resolved) dependencies - there are bits and pieces in jar-checks.gradle that should be relevant.

After that it's about deduping and generating .classpath; maybe manually filtering some stuff.

Should be doable, but some trial and error is definitely in order.

asfimport commented 4 years ago

Dawid Weiss (@dweiss) (migrated from JIRA)

I implemented basic support for "everything-in-one-bin" Eclipse project. Imports and compiles for me. I didn't try to emulate the stuff in ant's xslt file because I don't know what it was used for. I would commit this in and let people shout when something doesn't work or is missing.

asfimport commented 4 years ago

Erick Erickson (@ErickErickson) (migrated from JIRA)

@dweiss Many thanks, It Will Be Done Real Soon Now, probably today since I'd like to get this off hold.

asfimport commented 4 years ago

Dawid Weiss (@dweiss) (migrated from JIRA)

Hey, Robert (@rmuir) is this something that works for your needs?

asfimport commented 4 years ago

ASF subversion and git services (migrated from JIRA)

Commit b1e2d0c8906615a4de41511fbd1bd663908b7195 in lucene-solr's branch refs/heads/master from Dawid Weiss https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b1e2d0c

LUCENE-9438: Eclipse IDE support with gradle build system (#1761)

asfimport commented 4 years ago

Dawid Weiss (@dweiss) (migrated from JIRA)

I've pushed this in, doesn't seem to be clashing with any other effort anyway.

asfimport commented 4 years ago

ASF subversion and git services (migrated from JIRA)

Commit 66eb9f7f3d7f12bf300db9dfd4dd80bb491547cb in lucene-solr's branch refs/heads/master from Dawid Weiss https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=66eb9f7

LUCENE-9438: moved eclipse template files under corresponding gradle's script.

asfimport commented 4 years ago

Adrien Grand (@jpountz) (migrated from JIRA)

This worked well for me to get the project to compile, but running tests doesn't work as resources are not on the classpath, so codecs are not loaded. I had to do the following to make it work

diff --git a/gradle/ide/eclipse.gradle b/gradle/ide/eclipse.gradle
index e414112697a..12e1bdc95a6 100644
--- a/gradle/ide/eclipse.gradle
+++ b/gradle/ide/eclipse.gradle
`@@` -47,6 +47,7 `@@` configure(rootProject) {
           projects.each { prj ->
             prj.sourceSets.each { sourceSet ->
               sources += sourceSet.java.srcDirs.findAll { dir -> dir.exists() }.collect { dir -> relativize(dir) }
+              sources += sourceSet.resources.srcDirs.findAll { dir -> dir.exists() }.collect { dir -> relativize(dir) }
             }

             // This is hacky - we take the resolved compile classpath and just

This might not be the best way to do this as I have very little Groovy/Gradle knowledge.

asfimport commented 4 years ago

Dawid Weiss (@dweiss) (migrated from JIRA)

This is correct, Adrien. Please commit it in! Separately from this, I'd really recommend trying IntelliJ IDEA as its support for classpath resolution and scopes is much superior to Eclipse's.

asfimport commented 4 years ago

ASF subversion and git services (migrated from JIRA)

Commit 7f68272575bb8ab9157f6c6f806d2640fd4cf31d in lucene-solr's branch refs/heads/master from Adrien Grand https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7f68272

LUCENE-9438: Add resources to the Eclipse classpath.

asfimport commented 2 years ago

Adrien Grand (@jpountz) (migrated from JIRA)

Closing after the 9.0.0 release