I have a multi module project with the following structure:
root_project
module1
module2
module3
I try to apply the java plug-in to all projects using the following code:
allprojects {
apply plugin: 'java'
group = 'com.mysoftware'
sourceCompatibility = 1.8
version = '1.3'
repositories {
mavenCentral()
}
}
Additionally I add the javafx plugin to module3. The java and javafx tasks are now shown in the intellij gradle view, but when trying to execute them, I get this error:
Task 'jfxJar' not found in root project 'module3'.
Furthermore, running the tasks task show me that neither the java tasks nor the javafx tasks are available, despite being shown in the gradle view in intellij.
I tried rebuilding and refreshing the whole project without success. I use the Use default gradle wrapper configuration.
The error message you got Task 'jfxJar' not found in root project 'module3' indicates that Gradle considers the subproject module3 as a Root project: this can happen if you created a settings.gradle file in the sub-project directory, which is not a valid setup (only one settings.gradle file can exist in a multiproject build, located in the root directory)
Related
I have a gradle build with Java sub-projects and had a jacoco task defined in the root build.gradle which I'm moving to the sub-projects that only use it.
By doing that though I am hitting an issue in the ear deploymentDescriptor task where and there are multiple webModule definitions.
The error I'm seeing in the IDE and gradle command line is:
A problem occurred evaluating project ':deployear'.
> Could not get unknown property 'war' for project ':sub-project-two' of type org.gradle.api.Project.
My ear build.gradle contains
apply plugin: 'ear'
ear {
archiveName = 'web-application.ear'
appDirName 'src/main/application'
libDirName 'APP-INF/lib'
deploymentDescriptor {
fileName = "application.xml"
version = "1"
description = "My Web Application"
initializeInOrder = true
displayName = "Web Application"
webModule(project(":sub-project-one").war.archiveName, "context-root/one")
webModule(project(":sub-project-two").war.archiveName, "context-root/two")
}
}
If I comment out webModule(project(":sub-project-two").war.archiveName, "context-root/two") then the project builds successfully.
Both sub-project-one and sub-project-one have java and war plugins applied.
Is there a reason why moving a jacoco dependency from a parent build.gradle to some sub-project build.gradle files would generate this error?
Found a work around.
In my deployear sub-project I added
apply plugin: 'ear'
evaluationDependsOn(':sub-project-two')
and that forced the deployear sub-project to evaluate the sub-project-two project prior to running the ear task.
I thought the same could be done with changing the ordering in the parent settings.gradle but that didn't work for me.
I am trying create an Gradle multi project similar to this structure
ouat-services
- ouat-contract
- ouat-servicesImpl (web project)
I followed the eclipse example and define my ouat-services settings.gradle as
include "ouat-contract", "ouat-servicesImpl"
In my ouat-servicesImpl build-gradle I define
dependencies {
compile project(':ouat-contract')
}
My problem starts when I try apply war plug-in in ouat-servicesImpl, I receive the following message in eclipse problem view:
Invalid classpath publish/ export dependency /ouat-contract. Project entries not supported
My ouat-services build.gradle
configure(subprojects) {
apply plugin: 'com.github.ben-manes.versions'
apply plugin: 'eclipse'
apply plugin: 'java'
version = '1.0'
sourceCompatibility = 1.8
targetCompatibility = 1.8
def defaultEncoding = 'UTF-8'
[compileJava, compileTestJava]*.options*.encoding = defaultEncoding
repositories {
jcenter()
mavenLocal()
mavenCentral()
}
jar {
manifest.attributes provider: 'Company'
}
}
configure(project(':ouat-servicesImpl')) {
apply plugin: 'checkstyle'
apply plugin: 'eclipse-wtp'
apply plugin: 'findbugs'
apply plugin: 'jacoco'
//apply plugin: 'jetty'
apply plugin: 'pmd'
apply plugin: 'war'
}
buildscript {
repositories {
jcenter()
mavenCentral()
mavenLocal()
}
dependencies {
classpath 'com.github.ben-manes:gradle-versions-plugin:0.10.1'
}
}
My ouat-servicesImpl build gradle was changed to:
dependencies {
compile project(':ouat-contract')
cxfArtifacts.each { artifact ->
compile "org.apache.cxf:$artifact:$cxfVersion"
}
springArtifacts.each { artifact ->
compile "org.springframework:$artifact:$springVersion"
}
testCompile "org.testng:testng:$testNGVersion"
testCompile "org.hamcrest:hamcrest-all:$hamcrestVersion"
testCompile "org.springframework:spring-test:$springVersion"
//WAR PLUGIN
providedCompile "javax.servlet:javax.servlet-api:$servletAPIVersion"
runtime "javax.servlet:jstl:$jstlVersion"
}
Is this an eclipse plug-in problem or I am doing something wrong?
Here's the magic steps I've discovered to make it work without messing with Project settings manually.
Run command: gradle cleanEclipse eclipse
as a result of this command Eclipse forgets that the project was supposed to have a gradle nature.
Add gradle nature back to the project by doing Configure -> Convert to Gradle Project.
as a result of this command the error reappears.
if incompatible plugin java version error appears then just delete .settings directory and refresh.
Run command: gradle cleanEclipseClasspath eclipseClasspath
this final step should get it fixed until the next time.
In my case, this was due to mixing "faceted" and non-faceted projects. The projects with the error had been converted to faceted form, and the project they referenced which it was complaining about had not been. You can configure the project to be faceted via use of the eclipse-wtp plugin, by adding this to your ouat-contract gradle file:
eclipse{
wtp{
facet{}
}
}
This will add facets for Java and a utility module when using the java and war plugins (see the EclipseWTPFacet documentation for more information on the defaults and manually adding facets if you aren't using the war plug-in). The utility module part is the key to avoid the error.
Note that within this block you can also access the facet file directly to perform manual XML manipulation if you need to do other things, like specify a particular Apache Tomcat Runtime or or similar
Once you make this change, you can use Eclipse to do Gradle -> Refresh All on ouat-contract within your workspace - once I did this, the error went away
I've also run into this problem long time ago. It really seems to be the problem related to the Eclipse plugin included in "Gradle IDE Pack" (as it works from the command line without problems).
My setup is probably way more complex than Yours (I'm including modules from one top-level gradle project into another top-level gradle project), but to overcome this specific error
Invalid classpath publish/ export dependency /my-project. Project entries not supported
... i excluded project dependency if some specific gradle property was missing:
if(project.hasProperty("myProjectRefAddedFromIDE")) {
println "NB! Build script started with property 'myProjectRefAddedFromIDE' - expecting that this project in IDE is configured to add the direct reference to my-project"
} else {
compile project(':my-project')
}
And to add the property "myProjectRefAddedFromIDE" only from IDE, i have configured eclipse plugin as follows:
Window -> Preferences -> Gradle -> Arguments -> Program arguments -> Use: ´-PmyProjectRefAddedFromIDE´
Just a warning: this will probably work for you, but there might be some other problem with Your setup, as for simple multi-module project (that doesn't include modules form another multi-module project) I don't have to use this workaround.
This works for me to remove the duplicate jar files from JRE System Library.
Steps Right click on Project and go to Build Path->configure build path->Libraries.
Remove the jars that are not in the classpath or duplicated in Maven dependency.
I have the following project structure:
my-project
+my-project-data
+my-project-service
+my-project-example
Where each of these my-project-data, my-project-service, my-project-examples are defined as sub project to my-project in settings.gradle file. Of course, my-project-services has a dependency to my-project-data. And my-project-examples has a dependencies to my-project-data and my-project service.
In the project my-project-examples I want to have some class with main method and make some queries to DB (Assume that main class is in package com.project.main). Moreover I want to execute this in command line:
java -jar my-project.jar
But to do this I have to set Main-Class attribute. Where do I have to do this in root project build.gradle or somewhere else and what have to be the value of attribute?
You can use the application plug-in which provides exactly what you need.
Add the following to your example's project build.gradle:
apply plugin: 'application'
mainClassName = "com.company.package.YourClassWithMain"
Then, simply run the sample by executing 'gradle run' (or using gradle wrapper) under the example project directory.
My web app is build using two projects one that contains the api and second web part. In Eclipse I am able to use classes from project-api in project-web however in deploy I have exception:
Caused by: java.lang.ClassNotFoundException: project.api.TestApi
This is my main build.gradle file:
sourceCompatibility = 1.7
subprojects {
apply plugin: 'java'
}
This is build.gradle from api:
apply plugin: 'java'
apply plugin: 'eclipse'
repositories {
mavenCentral()
}
dependencies {
}
And this is part of my build.gradle from web:
dependencies {
compile project(':project-api')
...
}
If I go and see web app libraries I can't see anything like project-api.jar. Wham am I doing wrong?
UPDATE:
It is issue only in eclipse. If I run gradlew war and deploy this manually to tomcat I can deploy it without any issued. project-api.jar is included in war. I tried already to run few times
`gradlew clean cleanEclipse eclipse`
but it doesn't help. I also try to reimport projects in eclipse but still the same.
EDIT:
This project is a spring mvc app and I just discovered that when I build war from gradle I am able to deploy war manually without any errors. Issue is only when trying to deploy via eclipse.
EDIT: Here is settings.gradle
rootProject.name = 'project'
include 'project-test'
include 'project-web'
include 'project-api'
You need to convert the dependencies of the deployable project to a "faceted project".
Project properties -> Project Facets -> Convert to faceted form...
Then mark each dependency as a "Utility Module".
I have a multi-module project with a directory structure like:
proj
|-modA
|-modB
|-modMain
\-modSysTest
The dependencies are:
modB -> modA
modMain -> modB
modMain -> modA
modSysTest -> modMain
We currently use Ant as our build system. Every module has a build.xml. There is a master.xml that runs the multi-module build, which is in modMain.
I am investigating switching our project to use gradle. I can get a multi-module build working if I put a build.gradle and settings.gradle in a new sibling directory and set up the dependent modules using includeFlat.
I tried moving the gradle files into modMain, which is the home of both the main component of our system as well as the top-level build script (master.xml) that builds the whole system, but I cannot get the build working this way. My main stumbling block at the moment is trying to configure modSysTest to depend on modMain from within modMain.
Here is the settings.gradle from modMain:
includeFlat 'modA', 'modB', 'modSysTest'
Here is the build.gradle file from modMain:
allprojects {
apply plugin: 'java'
repositories {
mavenCentral()
};
dependencies {
testCompile 'junit:junit:4.11'
}
}
project(':modB') {
dependencies {
compile project(':modA')
}
}
project(':modSysTest') {
dependencies {
compile project(':modMain')
}
}
dependencies {
compile project(':modA'), project(':modB')
}
When using this configuration, I get the error:
A problem occurred evaluating root project 'modMain'.
> Project with path ':modMain' could not be found in project ':modSysTest'.
I am not sure how to specify modMain as a dependency for modSysTest.
The project path of the root project is :, not :modMain. It's not very customary (but possible) to have code in the root project. I don't see how putting build.gradle and settings.gradle into a sibling directory of modMain would give a different result (unless you also changed the contents of settings.gradle). Note that with such a setup, Gradle won't find settings.gradle unless you start the build from the modMain directory or pass the location of the settings file with -c.