Quick reference:
https://github.com/korlibs/korge-next
How do I run or include the samples directory for compilation?
In the settings.gradle file, you can include individual samples project like this:
include(":samples:fleks-ecs")
You can also just include the entire samples directory, but this is not recommended as it takes awhile to build.
Related
I really don't have much experience in developing let alone using build tools.
I was assigned a task to build dependencies locally and get the jar files.
say I have a list of deps (GAV) like this:-
1. org.jetbrains.kotlin:kotlin-stdlib:1.6.0-RC
2. com.auth0:java-jwt:3.18.2, etc
3. openapi4j:openapi-operation-validator:1.0.7, etc
So i was able to download the source code url from maven repository and source code from github programmatically, for example :-
org.jetbrains.kotlin:kotlin-stdlib:1.6.0-RC - https://github.com/JetBrains/kotlin
com.auth0:java-jwt:3.18.2 - https://github.com/auth0/java-jwt
openapi4j-openapi-operation-validator-1.0.7 https://github.com/openapi4j/openapi4j
but there are many build.gradle files in different directories, how do I know which directory should I move into before running the gradle build command.
Things I have already tried and failed:-
For deps like this openapi4j:openapi-operation-validator:1.0.7, i can directly go into the openapi-operation-validator folder in the Github repo (https://github.com/openapi4j/openapi4j ) and run the gradle build command, but not all projects are structured like that I guess?
For deps like this com.auth0:java-jwt:3.18.2, the artifactId (java-jwt
) is already present in the github path (https://github.com/auth0/java-jwt), so i can run the gradle build command on the root github repo.
From the spring guides , among all the Gradle.build files available I can check which file has:-
jar {
archiveBaseName = <artifactId>
archiveVersion = <version>
}
, then I can move to that dir and run Gradle build, but not all build.gradle files have this.
None of the above approaches are concrete, is there any other firm approach that I can use to tackle the problem?
Your approach is generally correct.
You need to find the source code in github/gitlab/wherever, read the readme file and try to build it with whatever build tool was used there.
This may or may not work.
I was working on a maven project and this project is generating some weird file.
The file name are like:
[PROJECT]/target/classes.531226305.timestamp
[PROJECT]/target/classes.1241815416.timestamp
[PROJECT]/target/test-classes.-1983166104.timestamp
And the content of the file are only a .(dot) inside it. Anyone has any idea of how this is generated? Thanks!
Does the project use the scala-maven-plugin? The scala-maven-plugin adds ".<hashcode>.timestamp" to files in the target directory. It's used for the incremental compile feature that is available for that plugin.
Current my scanner is running through and only scanning the parent and skipping the rest of my nested files. If I run sonarlint (using the cli and specifying some test and source files) , it tries to analyze 37k files instead of the few I need. I have been able to skip ~3k files by adding the <sonar.skip>true</sonar.skip> property to a pom file. However, I still can't configure the project to run across certain sub-folders and print out some kind of code coverage test. (Is JaCoCo needed for the latest version(6.3,0)? Or can code-coverage be handled through some configuration?).
If Sonar seems to be analyzing too many files, it is probably because you had not set the sonar.sources=src/main/java in your sonar-project.properties file, so it defaults to the basedir and includes everything.
SonarQube can't do code-coverage itself, it just reports on coverage-reports from a tool like JaCoCo. It is funny they don't clarify these things in https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner --but with enough digging, you can find good info on that site.
Is there a way to exclude certain packages or source files when compiling in buildr? There isn't an exclude on the compile task as it looks in the src directory. We are building for multiple environments and for one of the environments we need to exclude a few source files otherwise it won't compile.
Any ideas?
thanks
compile.sources only contains the source directories and there is no way to tell buildr to exclude subdirectories directly from that. However, before compilation, buildr lists all the files in these directories to pass them on to the compiler (you can see this with buildr --trace compile). You could monkey-patch Buildr::Compiler::Base::files_from_sources to exclude some stuff, but that seems way too intrusive.
I would turn the problem upside down: instead of putting all the code in a single source directory, put environment-specific stuff in its own directory like so:
src/main/java
src/other-env/java
Most if not all IDEs support multiple source directories, so that should not be a problem.
Then define buildr projects for each of the environments by adding the appropriate source directory to the compilation path using compile.from (same for resources). If src/main/java compiles on its own, you could also separate that into its own project and have the others depend on it, thus avoiding having to recompile it over and over.
To make the build script simpler, think about making the various environments proper sub-projects.
I am setting up a Grunt project for the first time. Is there a recommended directory structure? For example, keep sources under /src, intermediate build artifacts in /stage and final concatenated, minified artifacts in /dist.
I am also using compass/sass. I assume my scss files should go under /src, but what's the correct way to set up the build workflow so that I am building and testing quickly while not cluttering my source directory with build artifacts.
I just have /src and /build (which is your /dist), and no /stage. I haven't found a real need for stage, probably because I don't have much integration testing to do. Let me know what you're using /stage for -- I'm curious. :)
/myproject
/build
/src
/css
/sass
I do have both a /sass and a /css. /css holds the single main.css compiled w/ SASS. In my Gruntfile.js, I have 2 SASS targets, sass:dev & sass:build. sass:dev compiles into /src/css and sass:build into /build/css. /src/css/main.css is git-/svn-ignored.
At the end of the day, Grunt doesn't care how you organize your sources. It just assumes Gruntfile.js and /node_modules are at project root, and that's it. It's actually NPM that assumes package.json's at root.
So, try different structures and settle on one that you like, which always depends on what tools you use.
Hope this helps! :)
Running grunt init:jquery or grunt init:node should give you a pretty good start on answering this question.
Here is the result of running grunt init:jquery inside a directory called init_test and selecting the default answer for grunt-init's prompts.
Writing CONTRIBUTING.md...OK
Writing grunt.js...OK
Writing libs/jquery/jquery.js...OK
Writing libs/jquery-loader.js...OK
Writing libs/qunit/qunit.css...OK
Writing libs/qunit/qunit.js...OK
Writing README.md...OK
Writing src/init_test.js...OK
Writing test/init_test.html...OK
Writing test/init_test_test.js...OK
Writing LICENSE-MIT...OK
See https://github.com/gruntjs/grunt-init