Whenever I start a new Java+Gradle project, I create the following directory structure manually:
project-name
|
|--- build.gradle
|
|--- .gitignore
|
|--- src
|--- main
| |---java
|
|--- test
|---java
Since this is a fairly standard structure, I imagine there must be a plugin/command/task for Gradle that would do this scaffolding for me. Is there such a plugin/command/task available? If not, can I write a task for that?
The following does the trick:
gradle init --type java-library
The task is provided by the init plugin
I achieved this kind of scaffolding using an init script. Have a look at my blog post about it.
There is a templates plugin available on github
Related
I have a problem moving packages in IntelliJ IDEA. I have created Maven project with multiple modules and each of those modules has a package with the same name. Now whole project becomes a mess if I try to rename some of the packages.
My current project structure is something like this:
--parent-module
|
|--module-one
| |--src
| |--main
| |--java
| |--somepackage
| |--someotherpackages
|--module-two
| |--src
| |--main
| |--java
| |--somepackage
| |--somemorepackages
|--module-three
|--src
|--main
|--java
|--somepackage
|--someevenmorepackages
Notice that somepackage is present in all maven modules.
After MANY created classes in all of those modules and packages I have finally realised what have I done. Now I need to put somepackage into another package under java so I can have something like com.example.moduleone.somepackage.
I have tried renaming package but it renames it in all modules and that creates hailstorm of errors in the code. Also, IntelliJ IDEA renames it to com.example.moduleone.somepackage in all of the modules.
Any help would be highly appreciated.
Might be easiest to create the new package first and then move the classes you want to move into it and then delete somepackage once everything have been moved around
So first add moduleone, then move all of the classes you want to move, then do the same for the other modules, then delete somepackage
Right click to Project name > New> Module..> chose java version and set name for new module.
Drag your packpage your want move to new-module/src > OK > Refactor.
Rebuild project. Find erro : java: packpage dose not exist. Fix it by: Go to erro code > Atl+Enter > Add depedency on module..
I have my project structured in this way:
projectRoot
+-src
+-main
| +-java
| | +-package/java files go here
| +-resources
| +-config
| +-files go here
+-test
+-java
| +-package/java files go here
+-resources
+-config
| +-files go here
+-features
+-files go here
When this project is built, it produces the following output structure:
projectRoot
+-out
+-production
| +-classes
| | +-package/classes in here
| +-resources
| +-config
| +-files in here
+-test
+-classes
| +-package/classes in here
+-resources
+-config
| +-files in here
+-features
+-files in here
This is all as expected. I have a task defined to run cucumber tests, which looks like this:
task runCucumber() {
doLast {
javaexec {
main = "cucumber.api.cli.Main"
args += ['--plugin', 'pretty', '--plugin', 'html:out/reports/cucumber/', '--plugin', 'json:out/reports/cucumber/report.json',
'--glue', 'com.example.mypackage.cucumber', 'classpath:features'
, '--tags', 'not #ignore']
systemProperties['http.keepAlive'] = 'false'
systemProperties['http.maxRedirects'] = '20'
systemProperties['env'] = System.getProperty("env")
systemProperties['envType'] = System.getProperty("envType")
classpath = configurations.cucumber + configurations.compile + configurations.testCompile + sourceSets.main.runtimeClasspath + sourceSets.test.runtimeClasspath
}
}
}
When I execute this task, my classes are not found and neither are features. Clearly, this is due to classpath not being set correctly. If I run the task with --info, I can see that the classpath is set using the parameter I indicated, however instead of out directories, it contains build directories. I expected the classpath to be:
<all dependencies>:/projectRoot/out/production/classses:/projectRoot/out/production/resources:/projectRoot/out/test/classes:/projectRoot/out/test/resources
Yet, the classpath contains the following:
<all dependencies>:/projectRoot/build/classes/java/main:/projectRoot/build/classes/java/test:
Interestingly, directory build is not produced at all under the project root. How can I set the classpath so that classes and resources can be found?
Ok, turned out the issue was not with Gradle but with IntelliJ IDEA. IDEA was overriding standard gradle paths and saving output in a different path from the one that gradle expected. Then, when the next gradle task ran, the output wasn't there. Compiling directly using gradle instead of IDEA solved the problem.
Very simple use case, I am using Eclipse Oxygen 4.7.3a that includes support from Java 9. I have two projects that are Java 9 projects:
- projectOne
| - src
| - module-info.java
| - com
| - package1
| - first
| Classificator.java
- projectTwo
| - src
| - module-info.java
| - com
| - package2
| - second
| Classifiable.java
I want to use the Classifiable class inside the Classificator, so I try to import the second module into the first project.
module-info.java Project 1:
module projectOne {
requires projectTwo;
}
module-info.java Project 2:
module projectTwo {
}
Eclipse is giving me the error:
projectTwo cannot be resolved to a module
Do I have to gather all my Java projects under one "main project" in order to let Eclipse know that all those modules are usable inside it? Or have I missed something else?
No, you don't need them to be in the same directory. Ideally, your project-one module defines some uses, which are implements by your project-two module (or vice-versa). Get the runtime implementation of your used interfaces. For this, both jars/classes must be on the module path.
For further information on module build, multi module builds,... you can refer to this link. Even if you do not use gradle, its tutorial on java 9 module build is quite interesting and gives some insight.
While wiring as a service is certainly a viable approach (as described in the other answer), let me add that requires can be made to work, too, of course.
The thing that was probably missing from the first approach is: Eclipse still needs to know where to look for modules. In real world projects this will typically be mediated by your build tool of choice plus a plug-in like m2e or buildship.
If no such plug-in is used, a normal project dependency should be added to the Build Path of project projectOne in order to make project projectTwo visible. Once the project is on the Build Path the module defined by the project can be resolved in references in module-info.java.
So I have two gradle projects: P1 and P2. P2 does not depend on P1 to build, however, during the build phase of P2, I want to build P1, add it to my resources folder and then add that folder to P2's jar.
I am still new to the whole gradle thing, so I am looking for an example build.gradle that would do something like this.
Thanks!
EDIT: It should be noted that P1 and P2 are both modules within the same project.
My project structure looks like this:
Root Project
Root Project
|
|__P1
| |
| |__build.grdale
|
|__P2
| |
| |__build.gradle
|
|__settings.gradle
My settings.gradle looks like this:
include 'P1', 'P2'
So I ended up finding a similar question here: Gradle: how to copy subproject jar to another subproject when task is run?
The build gradle should end up looking something like this:
task fix(dependsOn: ':P1:jar', type: Copy) {
from tasks.getByPath(':P1:jar')
into 'path/to/resources'
}
build.dependsOn fix
Given a Maven artifact (groupId:artifactId:version), how can I programmatically query its dependencies? (I don't need actually retrieve any artifacts, just the dependency information.)
Edit to add I'd like to do this outside of a Maven plug-in, and I'd like to build up a dependency graph.
If you're using a maven plugin (ie: extend AbstractMojo), you can do the following:
/**
* #parameter expression="${project}"
*/
private org.apache.maven.project.MavenProject mavenProject;
List<org.apache.maven.model.Dependency> depmgtdeps = mavenProject.getDependencyManagement().getDependencies();
That will give you the actual dependency objects that it detects. The MavenProject class has a bunch of other methods as well for reading various pom related things. However, I don't believe this works outside a plugin, or at least, I've never tried to do it.
I found these two links helpful..
A Maven Plugin for retrieving the dependencies
Using Eclipse Plugin
The following groovy script uses ivy to resolve dependencies
import groovy.xml.NamespaceBuilder
// Main program
// ============
def ant = new AntBuilder()
def ivy = NamespaceBuilder.newInstance(ant, "antlib:org.apache.ivy.ant")
ivy.resolve(
inline:true,
keep:true,
conf:"default",
organisation:"org.springframework",
module:"spring-core",
revision:"3.1.1.RELEASE",
)
ivy.report(toDir:"reports")
Generates a HTML report and a graphml file:
|-- report.groovy
|-- reports
| |-- ivy-report.css
| |-- org.springframework-spring-core-caller-default.graphml
| `-- org.springframework-spring-core-caller-default.html