When I create a Gradle project in Eclipse via the Buildship plugin I end up with two projects: one of them is called "lib". There is apparently no option to prevent this or even to rename the lib project to anything more meaningful.
A bug has been filed here but it's been closed because this is how the Gradle developers want our projects to be structured regardless of size or complexity.
The only workaround I know involves manual tweaking of the generated files.
Is there any way to make the Buildship plugin behave like it used to do in the past, with only a single maven-structured project?
Related
I'm trying out Java 9 Jigsaw module system (no module experience yet) and would like to use it for capsuling the classes within my project, but it's confusing.
According to this article it should be possible to have multiple modules within ONE project. I made a new project in Eclipse Oxygen (Java 9 is supported) with the same structure as shown in the article. But Eclipse keeps telling me that I must not have more than one module-info.java in a project.
I really don't know how to tell Eclipse that it should use the "multi-module-mode". And I really would appreciate not having to create a new project for every single module.
This works:
This not:
But according to this article something like that should work:
And how about deployment of a modularized project with Eclipse? There is nothing to see about the new jmod extension. Do I still export it as a runnable JAR file like before?
Notice that my questions refer to working with the IDE (no command line, I mean with an IDE that should be possible, right?) Thank you for enlightening me.
Currently, Eclipse requires you to create a separate project for each module (e. g. because each module has its own Java Build Path).
To understand this design decision, consider that Java modules correspond to OSGi bundles / Eclipse plug-ins and it has always been to have a separate project for each bundle/plug-in. If you come from the Maven world, you would probably expect a deeper folder structure instead. But modules are self-contained and combining several modules into one project would only add an additional folder level without meaning. However, Eclipse supports nested projects and so-called working sets if you need an additional folder level.
Exporting modules as images is planned for Eclipse 2019-03 (4.11), on March 20, 2019 (see Eclipse bug 518445). Exporting modules as JARs that can be used on the modulepath (-m) already works (see my video).
I don't know if this question is still open for an answer, but you can solve this problem by simply removing all source folders on the build path. At least this works for Eclipse 2021-12 version.
As you can see this is a demo project from the Official Gradle Guide Book and it has multiple modules. Each module has its own module-info.java.
project structure in IntelliJ IDEA
If I open this project in Eclipse it will give me the 'duplicated entries on module-info.java' error.
Eclipse shows the error
But if I delete all the source folders on the build path, the error is gone and the project can be built and run without problem.
project properties: Java build path
The only problem is that you have to build the project with Gradle so that it will produce the .jar of each module and you have to include them in the libraries later.
include all the .jar in libraries
I think this is probably the same solution mentioned by howlger above.
I'm having some trouble configuring Buildship for Eclipse the way I want. I currently have > 50 projects always open in Eclipse, but I want to move to having only the projects I am actively working on in Eclipse, and the other projects would use a Maven repository to resolve their dependency.
Lets say ProjectA (which contains a main) depends on ProjectB (a library project). If ProjectB is opened in Eclipse, I would like ProjectA to use ProjectB directly. A change in the code in ProjectB would be noticeable when running ProjectA. However, if ProjectB is closed, I would like ProjectA to use the ProjectB's JAR located in the Maven repository mentioned in the build.gradle file.
The behavior that I am talking about is detailed here.
Is there a way to do that using Buildship? Or should I use another Gradle Eclipse plugin?
There's a new composite build support feature added in Gradle 3.1. This feature is a game changer and makes it simple to work on more than one project at once.
You can use dependency substitution rules to swap out repository dependencies with local project dependencies.
If each project is within it's own separate git/subversion repository you can use prezi pride to manage the 'pride' of projects. You could import the (dynamically generated) multi module build into buildship.
If you wanted to use the eclipse plugin instead of buildship you use the whenMerged or withXml hooks to tweak the generated .classpath files to point to the projects within your workspace (note eclipse will now build differently to gradle command line).
For the sake of completion, I ended up going with the dependency substitution as suggested by Lance Java. This approach has the following advantages:
Does not require a third party software.
Is IDE independent. We're not tinkering with the .classpath file directly, we let the Eclipse plugin (or any other IDE plugin) handle this.
Other plugins can access the actual dependency we want to use.
However, there are some gotchas with that approach:
Dependency substitution cannot be done inside a task. It needs to be done either in the build.gradle file or in a method that is called from the build.gradle file.
You need to refresh the workspace.
My eclim setup working perfectly with eclipse project. But I want to use gradle build system.
I am working with Libgdx framework and it provide gradle templete project.
So is there any way to use eclime + eclipse + gradle
Your best bet is to check out the Eclipse Gradle plugin, although in short you can add apply plugin: 'eclipse' to your project and then run gradle eclipse from your terminal in the root folder of your project. That should generate the necessary files for Eclipse to recognize your project, although you might need to edit the .classpath file for proper autocompletions.
That will get Eclim to recognize your project with :ProjectOpen and proper autocompletion and other goodness.
The bad is that Gradle tasks and changes to your build.gradle will require manual changes to the Eclipse side of things.
Edit: There's a new plugin available for this purpose that replaces eclim for gradle projects (but is android oriented) called Vim-Grand. It's pre-alpha and you'll want the refactor branch for now, but it's working well enough for me
You should combine it with YouCompleteMe.
What I did was use the gdx-setup.jar to create my project. I then imported it into eclipse like a normal gradle project. I closed eclipse and started up elcimd. Put "let g:EclimCompletionMethod = 'omnifunc'" in my .vimrc file. Followed the elcim instructions to use :CreateProject and that was it.
This guide was really helpful: http://www.lucianofiandesio.com/vim-configuration-for-happy-java-coding
I am able to get most or all Eclim functionality working with my libgdx project this way:
create a new libgdx project with their tools
start Eclipse
Import --> Gradle Project --> Build Model per usual libgdx project creation
shut off Eclipse, start Eclim
I get organize imports, java validation, autocompletion, all the good stuff.
That said, I want to figure out how to do this all without having to use Eclipse. I think the missing piece is the Build Models functionality. Still researching ...
Part of a project I'm on has a GUI app that is built with Netbeans using the GUI design tools that come in that IDE.
But this is only part of a bigger project, and needs to be built in an environment that does not have Netbeans installed (it happens to be a Gradle-based build on Jenkins). I've gotten builds to (seemingly) work, but keep running into inexplicable run-time errors (i.e., dependencies appear to be met with identical jars on the classpath and so on, but attempts to read resources from the project jar fail.).
From googling around, it looks like this might have something to do with compiling .form files and then including some dependency for the resulting java. (though, the Netbeans build does not add any jars above what our gradle build adds).
So the question is... can this even be done? or does a proper build simply rely on some hidden build-time mojo that's going on in Netbeans?
Yes, you can compile the classes without NetBeans. Just be sure you do not any NetBeans library, like AbsoluteLayout. The .form files are for NetBeans showing you components with Matisse, but all the generated code will be in the .java file.
Here is the situation. A development team has a large number (hundreds) of Eclipse projects. The code is very much in churn - new projects are being created; projects are being renamed and project dependencies are constantly changing. The external build system is ant. It is proving extremely challenging to keep the dependencies defined in the ant build files in sync with the state of the world in Eclipse. The external ant build needs constant changes to keep up. For various reasons, using ant as the default builder in Eclipse is not an option. The developers want to continue using Eclipse as the build and edit environment for local use.
Question: Is there a tool which will allow a single set of dependencies to be maintained which can be used by Eclipse as well as an external build system like ant?
I have heard of Gradle but never used it before. Would it make sense in this context? I am pretty sure Maven wouldnt work for what is needed
The typical workflow should be:
1. Developers continue working as they currently do - creating and changing Eclipse project dependencies at will and using the default Eclipse builder to compile and test locally.
2. Some mechanism exists by which these dependencies can be carried into an external build system like ant and an external continuous build triggered on every checkin.
Appreciate your feedback - thanks!
We have been quite successful at using Gradle to tackle a similar problem. Here's the outline of the setup
Each project contains a build.gradle that defines project specific dependencies and tasks (may even be empty).
A special master project contains build.gradle that sets up common dependencies and tasks for child projects, and/or injects settings pertinent to a group of child projects.
Logically master project is the parent project, but it exists as a sibling folder so that Eclipse can be more comfortable with it.
Gradle contains a built-in Eclipse plugin which allows generation of Eclipse settings files for each of the projects from the dependencies information (including inter-project dependencies). It works nicely for simple projects, and as for more complicated ones Gradle allows you to tinker with the settings files, so you can do pretty much everything. From here you have two options:
Not to store Eclipse settings file in the repository and call the generation task every time you do a fresh check-out (I prefer this option).
Tell Gradle to use custom variables to make it generate generic settings files which can be checked-in to the repository. You'll then only need to run the generation task when dependencies or other configuration changes.
(Optional) It's a little tricky, but you can make Gradle parse existing project ivy.xml files and set up dependencies from there. I had some success with this, although I would recommend converting dependencies into Gradle format for more flexibility.
Continuous build system integrate with Gradle very well (same as ant). If you are using Jenkins (Hudson) there is a Gradle plugin.
The advantage of using Gradle is that it scales pretty well, and you can support other IDEs like IntelliJ or Netbeans at the same time without much effort (unless you have lots of crazy custom settings). An advantage and a disadvantage is that Gradle is a powerful build system which requires learning Groovy and Gradle DSL which may take some time to acquire. Also the documentation is awesome.
Gradle has a very active community with the sole purpose of tackling exactly this kind of problem.
Hope this helps, and best of luck!
How about parsing the .classpath files, generate a dependency tree and start building from the root. What you need is a convention on the layout of your projects or an generic (ant-) buildfile that could be changed in each project, if needed (e.g. different project layouts). I´m not sure if Eclipse Tycho could be used for that, since it´s a maven plugin(s) to build eclipse plugins or projects. But it´s able to resolve the bundle and project dependencies against maven repositories and eclipse update sites.