So I have:
buildSrc/
├── build.gradle
└── src
├── main
│ ├── groovy
│ │ └── build
│ │ ├── ExamplePlugin.groovy
│ │ └── ExampleTask.groovy
│ └── resources
│ └── META-INF
│ └── gradle-plugins
│ └── build.ExamplePlugin.properties
└── test
└── groovy
└── build
├── ExamplePluginTest.groovy
└── ExampleTaskTest.groovy
Question:
It seems like build.ExamplePlugin.properties maps directly to the build.ExamplePlugin.groovy. Is this the case? Seems terribly inefficient to have only one property in the file. Does it have to be fully qualified, i.e. does the name have to exactly match the full qualification of the class?
Now in the example, I see:
project.pluginManager.apply 'build.ExamplePlugin'
...however if I have that in my test, I get an error to the effect that the simple task the plugin defines, is already defined.
Why bother with test examples that require 'apply' when that is inappropriate for packaging?
Related
We have a gradle multi module project. api-1 is a dropwizard legacy project, and api-2 is the spring-boot project.
root-project
├── api-1
│ ├── build.gradle
│ ├── config
│ ├── libs
│ ├── src
│ │ ├── main
│ │ │ ├── java
│ │ │ └── resources
│ │ │ ├── META-INF
│ │ │ └── services
│ │ │ └── org.hibernate.integrator.spi.Integrator
├── api-2
│ ├── build.gradle
│ └── src
│ ├── main
│ │ └── resources
│ └── test
│ └── resources
├── gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
We have our entities in api-1 which we are trying to use in api-2. So in api-2's build.gradle file I included implementation project(':api-2'). It feels a lil bit coarse to import the module along with all its transitive dependencies in to this module; but for now I does the trick.
The Issue:
The problem here is that api-1 has hibernate 5.2 dependency and it has this org.hibernate.integrator.spi.Integrator file in the resource folder. It references org.hibernate.jpa.event.spi.JpaIntegrator. Apparently this class was removed from hibernate from version 5.3 (ref: https://github.com/hibernate/hibernate-orm/blob/5.3/migration-guide.adoc#jpaintegrator-removed )
Now when I run (task bootRun) my api-2 module, I it fails with the below exception:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaConfiguration.class]: Invocation of init method failed; nested exception is java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.jpa.event.spi.JpaIntegrator not found
What I Already Tried:
However if I delete this file (org.hibernate.integrator.spi.Integrator) from api-2, then api-2 runs and also api-1 seems to be running without any issues. But api-1 is a legacy project, and I am wary that it is wreck-less to simply remove the file without understanding it's implication fully.
I am trying to figure out if there is a safer way to get around this issue; maybe exclued that particular file in api-2. Or any better alternative?
I'm having some issues creating unit tests for my Puppet control repository.
I mostly work with roles and profiles with the following directory structure:
[root#puppet]# tree site
site
├── profile
│ ├── files
│ │ └── demo-website
│ │ └── index.html
│ └── manifests
│ ├── base.pp
│ ├── ci_runner.pp
│ ├── docker.pp
│ ├── gitlab.pp
│ ├── logrotate.pp
│ └── website.pp
├── role
│ └── manifests
│ ├── gitlab_server.pp
│ └── nginx_webserver.pp
Where do I need to place my spec files and what are the correct filenames?
I tried placing them here:
[root#puppet]# cat spec/classes/profile_ci_runner_spec.rb
require 'spec_helper'
describe 'profile::ci_runner' do
...
But I get an error:
Could not find class ::profile::ci_runner
The conventional place for a module's spec tests is in the module, with the spec/ directory in the module root. So site/profile/spec/classes/ci_runner_spec.rb, for example.
You could consider installing PDK, which can help you set up the structure and run tests, among other things.
I am trying to generate client code using k8s.io/code-generator.
These are the instructions that I am following: https://itnext.io/how-to-generate-client-codes-for-kubernetes-custom-resource-definitions-crd-b4b9907769ba
My question is, does my go module need to be present on a repository or can I simply run the generate-groups.sh script on a go module that is ONLY present on my local system and not on any repository?
I have already tried running it and from what I understand, there needs to be a repository having ALL the contents of my local go module. Is my understanding correct?
You CAN run kubernetes/code-generator's generate-groups.sh on a go module that is only present on your local system. Neither code-generator nor your module needs to be in your GOPATH.
Verification
Cloned kubernetes/code-generator into a new directory.
$HOME/somedir
├── code-generator
Created a project called myrepo and mocked it with content to resemble sample-controller. Did this in the same directory to keep it simple.
somedir
├── code-generator
└── myorg.com
└── myrepo # mock of sample-controller
├── go.mod
├── go.sum
└── pkg
└── apis
└── myorg
├── register.go
└── v1alpha1
├── doc.go
├── register.go
└── types.go
My go.mod looked like
module myorg.com/myrepo
go 1.14
require k8s.io/apimachinery v0.17.4
Ran generate-group.sh. The -h flag specifies which header file to use. The -o flag specifies the output base which is necessary here because we're not in GOPATH.
$HOME/somedir/code-generator/generate-groups.sh all myorg.com/myrepo/pkg/client myorg.com/myrepo/pkg/apis "myorg:v1alpha1" \
-h $HOME/somedir/code-generator/hack/boilerplate.go.txt \
-o $HOME/somedir
Confirmed code generated in correct locations
myrepo
├── go.mod
├── go.sum
└── pkg
├── apis
│ └── myorg
│ ├── register.go
│ └── v1alpha1
│ ├── doc.go
│ ├── register.go
│ ├── types.go
│ └── zz_generated.deepcopy.go
└── client
├── clientset
│ └── versioned
│ ├── clientset.go
│ ├── doc.go
│ ├── fake
│ ├── scheme
│ └── typed
├── informers
│ └── externalversions
│ ├── factory.go
│ ├── generic.go
│ ├── internalinterfaces
│ └── myorg
└── listers
└── myorg
└── v1alpha1
Sources
Go modules support https://github.com/kubernetes/code-generator/issues/57
Documentation or support for Go modules https://github.com/kubernetes/sample-controller/issues/47
I'm having trouble to import a generated package with Intellij, however without any changes to the default settings it works on Eclipse.
Here is my architechture:
├── build.properties
├── pom.xml
├── README.md
├── src
│ ├── main
│ │ ├── java
│ │ └── mypackage
│ └── test
└── target
├── classes
│ └── mypackage
| └── generated
├── generated-sources
├── generated-test-sources
├── APP.jar
└── test-classes
I have most of my classes in com.mypackage however some of them are generated in
└── target
├── classes
└── mypackage
named as com.mypackage.generated and i have to use these classes in com.mypackage:
├── src
├── main
├── java
└── mypackage
However intellij cannot resolve symbol generated when I'm doing
import com.mypackage.generated
I tried to make it work by looking at the project structure/modules/dependencies menu but it seems to be for external modules. How can I do this ?
Actually it was very simple, I only was about marking classes as sources root. I don't know why marking generated as sources root did not work.
I am trying to apply an example from the book Gradle in Action to learn how to separate a gradle application into subprojects. I did the example in the book and everything worked out fine.
I decided to apply the same concepts to a sample application from the Griffon Framework called minimalistic build, source code: sources. I selected this application because it follows the normal application structure instead of Griffon's, and I was trying to fill the gap (IMHO) in Griffon's documentation for multi project builds: it has one exaple that uses Open-Dolphin, Swing, JavaFX, Servlets that I felt it was too complicated to learn the basics.
Of course I hit the wall big time, multiple times...
Griffon's JavaFX application has the following structure:
├── build.gradle
├── config
│ └── HEADER
├── gradle
│ ├── functional-test.gradle
│ ├── integration-test.gradle
│ ├── javafx-plugin.gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradle.properties
├── gradlew
├── gradlew.bat
└── src
├── functional-test
│ └── java
│ └── org
│ └── example
│ └── SampleFunctionalTest.java
├── integration-test
│ └── java
│ └── org
│ └── example
│ └── SampleIntegrationTest.java
├── main
│ ├── java
│ │ ├── Config.java
│ │ └── org
│ │ └── example
│ │ ├── Launcher.java
│ │ ├── SampleController.java
│ │ ├── SampleModel.java
│ │ ├── SampleService.java
│ │ └── SampleView.java
│ └── resources
│ ├── application.properties
│ ├── griffon-icon-128x128.png
│ ├── griffon-icon-16x16.png
│ ├── griffon-icon-24x24.png
│ ├── griffon-icon-256x256.png
│ ├── griffon-icon-32x32.png
│ ├── griffon-icon-48x48.png
│ ├── griffon-icon-64x64.png
│ ├── griffon.png
│ ├── log4j.properties
│ ├── messages.properties
│ ├── META-INF
│ │ └── griffon
│ │ ├── griffon.core.artifact.GriffonController
│ │ ├── griffon.core.artifact.GriffonModel
│ │ ├── griffon.core.artifact.GriffonService
│ │ └── griffon.core.artifact.GriffonView
│ ├── org
│ │ └── example
│ │ └── sample.fxml
│ └── resources.properties
└── test
└── java
└── org
└── example
├── SampleControllerTest.java
└── SampleServiceTest.java
The build.gradle file content is:
// tag::plugins[]
plugins {
id 'java'
id 'idea'
id 'com.github.ben-manes.versions' version '0.12.0'
id 'com.github.hierynomus.license' version '0.11.0'
}
apply from: 'gradle/javafx-plugin.gradle'
apply from: 'gradle/integration-test.gradle'
apply from: 'gradle/functional-test.gradle'
// end::plugins[]
// tag::javafx[]
javafx {
mainClass = 'org.example.Launcher'
}
// end::javafx[]
// tag::dependencies[]
repositories {
jcenter()
mavenLocal()
}
dependencies {
compile "org.codehaus.griffon:griffon-javafx:${griffonVersion}"
compile "org.codehaus.griffon:griffon-guice:${griffonVersion}"
runtime('log4j:log4j:1.2.17') {
exclude group: 'ant', module: 'ant-nodeps'
exclude group: 'ant', module: 'ant-junit'
exclude group: 'ant-contrib', module: 'ant-contrib'
}
runtime 'org.slf4j:slf4j-log4j12:1.7.21'
testCompile "org.codehaus.griffon:griffon-javafx-test:${griffonVersion}"
testCompile 'pl.pragmatists:JUnitParams:1.0.5'
testCompile 'org.mockito:mockito-core:2.0.59-beta'
}
// end::dependencies[]
// tag::resources[]
processResources {
from(sourceSets.main.resources.srcDirs) {
exclude '**/*.properties'
exclude '**/*.xml'
}
from(sourceSets.main.resources.srcDirs) {
include '**/*.properties'
include '**/*.xml'
filter(org.apache.tools.ant.filters.ReplaceTokens, tokens: [
'application.name' : project.name,
'application.version': project.version,
'griffon.version' : griffonVersion
])
}
}
// end::resources[]
license {
header = rootProject.file('config/HEADER')
strictCheck = true
ignoreFailures = true
mapping {
java = 'SLASHSTAR_STYLE'
fxml = 'XML_STYLE'
}
ext.year = '2016'
exclude '**/*.png'
}
And the structure I was trying to achieve is:
├── build.gradle
├── config
│ └── HEADER
├── gradle
│ ├── functional-test.gradle
│ ├── integration-test.gradle
│ ├── javafx-plugin.gradle
│ └── wrapper
│ ├── gradle-wrapper.jar
│ └── gradle-wrapper.properties
├── gradle.properties
├── gradlew
├── gradlew.bat
├── launcher
│ ├── launcher-build.gradle
│ └── src
│ └── main
│ └── java
│ ├── Config.java
│ └── org
│ └── example
│ └── Launcher.java
├── resources
│ ├── resources-build.gradle
│ └── src
│ └── main
│ └── resources
│ ├── application.properties
│ ├── griffon-icon-128x128.png
│ ├── griffon-icon-16x16.png
│ ├── griffon-icon-24x24.png
│ ├── griffon-icon-256x256.png
│ ├── griffon-icon-32x32.png
│ ├── griffon-icon-48x48.png
│ ├── griffon-icon-64x64.png
│ ├── griffon.png
│ ├── log4j.properties
│ ├── messages.properties
│ └── resources.properties
├── service
│ ├── resources
│ │ └── META-INF
│ │ └── griffon
│ │ └── griffon.core.artifact.GriffonController
│ ├── service-build.gradle
│ └── src
│ ├── main
│ │ └── java
│ │ └── org
│ │ └── example
│ │ └── SampleService.java
│ └── test
│ └── java
│ └── org
│ └── example
│ └── SampleServiceTest.java
├── settings.gradle
└── view
├── src
│ ├── functional-test
│ │ └── java
│ │ └── org
│ │ └── example
│ │ └── SampleFunctionalTest.java
│ ├── integration-test
│ │ └── java
│ │ └── org
│ │ └── example
│ │ └── SampleIntegrationTest.java
│ ├── main
│ │ ├── java
│ │ │ └── org
│ │ │ └── example
│ │ │ ├── SampleController.java
│ │ │ ├── SampleModel.java
│ │ │ └── SampleView.java
│ │ └── resources
│ │ ├── META-INF
│ │ │ └── griffon
│ │ │ ├── griffon.core.artifact.GriffonModel
│ │ │ ├── griffon.core.artifact.GriffonService
│ │ │ └── griffon.core.artifact.GriffonView
│ │ └── org
│ │ └── example
│ │ └── sample.fxml
│ └── test
│ └── java
│ └── org
│ └── example
│ └── SampleControllerTest.java
└── view-build.gradle
I don't know if that structure is the one that makes more sense, but is the one I first thought of.
Regardless everything I tried I could not build this project and I am wondering if anyone could tell me if I made a mistake with the selection of the subprojects and what should be the content for the build files.
I created a zip file with the rearranged source here keeping the original build.gradle file untouched, with a settings.gradle file that makes Gradle properly recognize the new structure.
Thanks!
The problem is caused by missing resource files in the service project. You'll find a similar problem in the view project. This is is because all resource files were moved to another location (the resources project). There was no problem before splitting the application into subprojects because all resources were at the right place.
You can fix the build by following these steps:
$ cd service
$ mkdir -p src/test/resources
$ touch src/test/resources/Config.properties
$ mkdir -p src/main/resources
$ mv ../resources/src/main/resources/messages.properties src/main/resources/
$ cd ../view
$ mkdir -p src/test/resources
$ touch src/test/resources/Config.properties
This should be enough to make the tests green again.
Marcelo,
I've posted a new version of the multi-project build here. This version keeps common setup at the root level, leaving what's specific to each subproject on each subproject's build file.