The Gradle User Guide often mentions that Gradle is declarative and uses build-by-convention. What does this mean?
From what I understand it means that, for example, in java plugin there are conventions like
source must be in src/main/java,tests must be in src/main/test, resources in src/main/resources, ready jars in build/libs and so on. However, Gradle does not oblige you to use these conventions and you can change them if you want.
But with the first concept, I have a bigger problem with understanding. Like SQL you say what you want to do with your queries but do not say how the Database System will get them, which algorithm to use to extract the data etc.
Please, tell me more to understand these concepts properly. Thanks.
Your understanding of build by convention is correct, so I don't have to add anything there. (Also see Jeff's answer.)
The idea behind declarative is that you don't have to work on the task level, implementing/declaring/configuring all tasks and their dependencies yourself, but can work on a higher, more declarative level. You just say "this is a Java project" (apply plugin: "java"), "here is my binary repository" (repositories { ... }), "here are my sources" (sourceSets { ... }), "these are my dependencies" (dependencies { ... }). Based on this declarative information, Gradle will then figure out which tasks are required, what their dependencies are, and how they need to be configured.
In order to understand a declarative style of programming it is useful to compare and contrast it against an imperative programming style.
Declarative Programming allows us to specify what we want to get done.
In Imperative Programming we specify how we get something done.
So when we use gradle,as Peter describes, we make declarations, declaration such as, "This is a Java Project" or "This is a Java Web Application"
Gradle then, makes use of plugins that offer the service of handling the building of things like "Java Projects" or "Web Applications". This is nice because it is the Gradle Plugin that contains the implementation details that concerns itself with such tasks as compiling java classes and building war files.
Contrast this against another build system, Make, which is more imperative in nature. Lets take a look at a simple Make rule from taken from here:
foo.o : foo.c defs.h
cc -c -g foo.c
So here, we see a rule that describes how to build an object file foo.o from a C source file and a C header file.
The Make rule does two things.
The first line says that a foo.o file depends on a foo.c and foo.h. This line is kind of declarative in so far as Make knows how to check the timestamp on the file foo.o to see if it is older than the files foo.c and foo.h. and if foo.o is older then Make will invoke the command that follows on the next line.
The next line is the imperative one.
The second line specifies exactly what command to run (cc - a C compiler) when a foo.o file is older than either of the files foo.c or foo.h. Note also that the person who is writing the Makefile rule must know what flags that are passed to the cc command.
Build by convention is the idea that if you follow the default conventions, then your builds will be much simpler. So while you can change the source directory, you don't need to explicitly specify the source directory. Gradle comes with logical defaults. This is also called convention over configuration.
This part edited to be more clear about declarative nature based on Peter's answer:
The idea of the build being declarative is that you don't need to specify every step that needs to be done. You don't say "do step 1, do step 2, etc". You define the plugins (or tasks) that need to be applied and gradle then builds a task execution graph and figures out what order to execute things in.
Related
Motivation:
In our code we have a few places where some methods are run by their name. There are some big if-else-if blocks with each function name and call of the corresponding method (I use the term function to describe just names, for example function X01 might correspond to method SomeClass.functionX01). I've been looking into ways to improve that
Goal:
Write just methods that are annotated with some custom annotation, removing the need to update or even include if-else-if blocks in order to run specific function. Have access to any generated code if any code is generated.
What I did:
I've created first prove of concept using runtime annotations and it proved successful, but slower then if-else-if. Next attempt was with source annotation
I've followed this link for an example, however it did not seam to run in IntelliJ. What I wanted is to have - in this case PersonBuilder class generated, instead there was none. In some cases an error was raised Error:java: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider BuilderProcessor not found
After some Googling and failing to find anything I've turned to book (Core Java, Volume II - Advanced Features - 9th Edition, Polish translation) and there was reccomended to run the following commands:
javac [AbstractProcessor implementation]
javac -processor [Compiled Processor] [other source files to compile]
This worked, however is unsatisfactory as it needs to happen inside IDE (NetBeans and IntelliJ to be specific) automatically during build. Code does not need to be generated on the fly, but programmer must have access to it after build (as in - be able to call methods of generated classes)
Question:
How to have and use generated code used in NetBeans and IntelliJ without the need of using external tools? Is it possible, or using reflection, runtime annotations or external tools is the only way?
Additional info (just in case):
Language level: Java 1.8
JVM versions: 12 and 13
IDEs: NetBeans and IntelliJ
We already tried the approaches as listed below:
https://github.com/oliverlockwood/jenkinsfile-idea-plugin
https://st-g.de/2016/08/jenkins-pipeline-autocompletion-in-intellij
After having searched the web for many hours on multiple days, we still haven't found a helpful resource on this matter. Thus, it appears to make sense to ask a new question here.
We are developing our Java projects in IntelliJ idea and want to integrate our builds with Jenkins. When we create a Jenkinsfile in Idea, we do not get syntax highlighting or auto completion. Since we are new to Jenkins, those features would be really useful to us. How can we make Idea be more supportive with Jenkinsfiles?
If there is no way to get syntax highlighting and auto completion for a Jenkinsfile in IntelliJ IDEA, what other editors would be helpful?
Please note:
we are working with Java projects, not Groovy projects.
We've already tried the plugin https://github.com/oliverlockwood/jenkinsfile-idea-plugin. When the plugin is activated, the Jenkinsfile is recognized as such, but instead of syntax highlighting we get an error message, please see below.
pipeline {
agent { docker 'maven:3.3.3' }
stages {
stage('build') {
steps {
sh 'echo Hello, World!'
}
}
}
}
IntelliJ IDEA highlights the p of pipeline as error. The error message reads:
JenkinsTokenType.COMMENT, JenkinsTokenType.CRLF or
JenkinsTokenType.STEP_KEY expected, got 'p'
Thanks for any help!
If you want IDEA to recognize a Jenkinsfile as a Groovy file, then you can add the String "Jenkinsfile" as a valid file name pattern (normally contains file endings) for Groovy files. This is supported "out of the box" without requiring any additional Plugin (except the "Groovy" Plugin, but that is already part of IDEA).
To do that go to the settings menu, open the "Editor" item and then "File Types". Now select "Groovy" in the upper list and add "Jenkinsfile". You can also use a regex like "Jenkinsfile*" if you want to be more flexible regarding an optional file ending for the Jenkinsfile.
The setting should now look like this:
Your example now looks like this in IDEA (with the Dracula theme):
So IDEA now provides syntax highlighting and auto completion as far as I can tell. It suggests existing function/method names while writing, but I'm not a Groovy developer, thus I can't tell if some suggestions are missing.
At long last we found a solution that works for us and provides syntax highlighting and code completion for the Jenkinsfile present in an otherwise normal Java project in Idea.
The solution is taken from here, here (and from additional personal experiments / research)
Download the Groovy SDK (if you did not do so already) from the Groovy Page and configure it on your Java project. For help on this see here
Download the pipeline GDSL file from your Jenkins instance which should be available under a link like https://yourJenkinsInstance.tld/pipeline-syntax/gdsl, and add it to the classpath of your Java project. E.g. by creating a new folder src/main/jenkins, putting the pipeline gdsl file there and marking the folder as source root in IntelliJ Idea
Add "Jenkinsfile" as a valid file name pattern for groovy files as described here
To avoid the error message 'node' cannot be applied to '(groovy.lang.Closure<java.lang.Object>), you can add this line at the top of your Jenkinsfile:
// noinspection GroovyAssignabilityCheck
If you add
#!groovy
header to your jenkinsfile then you should get groovy syntax highlighting in IDE.
Another option is to use a shabang on top of the Jenkinsfile like this #!/usr/bin/env groovy. Also you can try out gdsl: https://st-g.de/2016/08/jenkins-pipeline-autocompletion-in-intellij
but so far it doesn't support declarative pipelines: https://issues.jenkins-ci.org/browse/JENKINS-40127
Looking at the source code, it looks like COMMENTS are not defined (they are commented out in the code)
The STEP_KEY is defined as: STEP_NAME="sh" | "parallel"
I'm not sure the plugin does much more and it hasn't been updated in 2 years.
go to the settings menu, open the "Editor"--> "File Types". Now select "Groovy" in the upper list and add ".Jenkinsfile". You can also use a regex like ".Jenkinsfile" if you want to be more flexible regarding an optional file ending for the Jenkinsfile.
Jenkinsfile is a groovy like script, but normally IntelliJ map it to TextMate editor.
To do that go to the settings menu, open the "Editor" item and then "File Types". Now select "TextMate" in the upper list and add "Jenkinsfile". You can also use a regex like "Jenkinsfile*" if you want to be more flexible regarding an optional file ending for the Jenkinsfile.
Use sh like this and the error should go away (worked for me)...
steps {
sh """
echo 'Hello, World!'
"""
}
I just received a third party authentication library to use in my clients application. I didn't receive any documentation with it and am trying to dig through the source and see how it works. I'm very to new Java when i click Go To -> Declaration on methods in IntelliJ it sends me to a .class file and i see a bunch of stubbed methods with /* compiled code */ in the methods.
I'm fairly sure this is common in Java i just don't know what to search for to learn about what exactly is going on. Any clarification would be great.
This typically meant that you don't have the source code, and IntelliJ IDEA would just display /* compiled code */ as a placeholder for the source code you don't have. I believe this has now changed, and IntelliJ comes bundled with a full Java decompiler plugin, and will display the decompiled source code as standard.
To better see what's going on, the best would be to receive the actual source code of the third party library.
You should of course also get the documentation, as reading the source code and guessing how to use a library usually isn't the best way to learn.
The second best option would be use the decompiler plugin in IntelliJ, that will automatically decompile the Java class file (note that the license for your third party library may disallow you to do just that). This will never be a 100% solution, but in most cases it's better than nothing.
You should really search/ask for documentation. Javadoc usually is invaluable if the method does stuff you can't guess from its name. Otherwise use a decompiler such as JD-GUI.
.java sourcecode is compiled to .class bytecode by compilers such as javac. The compiler may optimise specific things, and a compilation-decompilation process if highly unlikely to yield the same source. Also, all comments should be deleted and if the code wasn't compiled in debug mode, even the variable names are lost. So: Decompilation is not a good alternative to handcrafted documentation.
If your library is build with sourceFiles:
task androidSourcesJar(type: Jar) {
classifier = 'sources'
from android.sourceSets.main.java.sourceFiles//look at this line
}
Then you will see classes with /* compiled code */
If your library is build with srcDirs:
task androidSourcesJar(type: Jar) {
classifier = 'sources'
from from android.sourceSets.main.java.srcDirs//look at this line
}
Then you will see classes with full source without /* compiled code */
If you are using Findbugs for compiled code inspection, is it possible to fail a build based on the result of a single detector or category of detectors?
For example, I would like to ensure that I don't have any null pointer-related detections (prefix of "NP" in this list) of any priority. Likewise, we really don't want to have any wait not in loop situations. That said, I don't necessarily want to fail a build based on internationalization detections as those aren't immediately critical to our application.
The desired end-state would be a process that we could tune for a variety of development phases ranging from the IDE level (Eclipse and Netbeans) to the release level (builds are generated using CruiseControl).
NOTE: I am aware that Eclipse and Netbeans both have similar detection methods built-in but this is a FindBugs specific question.
From the FindBugs Using the Ant Task section:
includeFilter
Optional attribute. It specifies the filename of a filter specifying which bugs are reported. See Chapter 8, Filter Files.
From Chapter 8:
However, a filter could also be used to select bug instances to specifically report:
$ findbugs -textui -include myIncludeFilter.xml myApp.jar
and
Match certain tests from all classes by specifying their abbreviations.
<Match>
<Bug code="DE,UrF,SIC" />
</Match></pre>
So I would assume something along the lines of:
<Match>
<Bug code="Wa,NP" />
</Match>
In your include filter and
<findbugs includeFilter="path/to/includefilter.xml"...
Would be what you're looking for.
The path/to /includeFilter (or excludeFilter) could be a property that gets set based on the value of another property which could default to something like dev for regular builds, test for CI builds, and deploy for deployment builds and specify which specific warnings you want to see or don't want to see at each stage.
Hope that helps.
I'm a longtime C++ programmer, new to Java. I'm developing a Java Blackberry project in Eclipse. Question - is there a way to introduce different configuration sets within the project and then compile slightly different code based on those?
In Visual Studio, we have project configurations and #ifdef; I know there's no #ifdef in Java, but maybe something on file level?
You can set up 'final' fields and ifs to get the compiler to optimize the compiled byte-codes.
...
public static final boolean myFinalVar=false;
...
if (myFinalVar) {
do something ....
....
}
If 'myFinalVar' is false when the code is compiled the 'do something....' bit will be missed out of the compiled class. If you have more than one condition - this can be tidied up a bit: shift them all to another class (say 'Config.myFinalVar') and then the conditions can all be kept in one neat place.
This mechanism is described in 'Hardcore Java'.
[Actually I think this is the same mechanism as the "poor man's ifdef" posted earlier.]
you can manage different classpath, for example, implement each 'Action' in a set of distinct directories:
dir1/Main.java
dir2/Action.java
dir3/Action.java
then use a different classpath for each version
javac -sourcepath dir1 -cp dir2 dir1/Main.java
or
javac -sourcepath dir1 -cp dir3 dir1/Main.java
In JDK6, you can do it by using Java's ServiceLoader interface.
Check it here.
If you want this specifically for BlackBerry, the BlackBerry JDE has a pre-processor:
You
can enable preprocessing for your
applications by updating the Eclipse™
configuration file.
In C:\Program Files\Eclipse\configuration\config.ini,
add the following line:
osgi.framework.extensions=net.rim.eide.preprocessing.hook
If you enable preprocessing after you
have had a build, you must clean the
project from the Project menu before
you build the project again.
Then you can do things in the code like:
//#ifdef SOMETHING
// do something here
//#else
// do something else
//#endif
For details see Specifying preprocessor defines
Can one call that a poor mans ifdef: http://www.javapractices.com/topic/TopicAction.do?Id=64?
No, Java doesn't have an exact match for that functionality. You could use aspects, or use an IOC container to inject different implementation classes.
You can integrate m4 into your build process to effectively strap an analogue to the C preprocessor in front of the Java compiler. Much hand-waving lies in the "integrate" step, but m4 is the right technology for the text processing job.
Besides Maven, Ant and other build tools that provide similar functionality, one would rather build interfaces in Java and switch the implementations at Runtime.
See the Strategy Pattern for more details
In opposite to C/C++ this will not come with a big performance penality, as Javas JIT-compiler optimizes at runtime and is able to inline this patterns in most cases.
The big pro of this pattern is the flexibility - you can change the underlying Implementation without touching the core classes.
You should also check IoC and the Observer Pattern for more details.
You could use maven's resource filtering in combination mit public static final fields, which will be indeed get compiled conditionally.
private static final int MODE = ${mode};
...
if (MODE == ANDROID) {
//android specific code here
} else {
}
Now you need to add a property to your maven pom called "mode", which should be
of the same value as your ANDROID constant.
The java compiler should (!) remove the if and the else block, thus leaving your android code.
Not testet, so there is no guarantee and i would prefer configuration instead of conditional compilation.
There are a couple of projects that bring support for comment-based conditional compilation to Java:
java-comment-preprocessor
JPSG
Example in JPSG:
/* with Android|Iphone platform */
class AndroidFoo {
void bar() {
/* if Android platform */
doSomething();
/* elif Iphone platform */
doSomethingElse();
/* endif */
}
}
In eclipse you could use multiple projects
Main (contains common code)
Version1 (contains version1 code)
Version2 (contains version2 code)
Main -> Select Project->Properties->Java Build Path->Projects tab
Select Add...
Add "Version1" xor "Version2" and OK back to the workspace.
Version1 and Version two contain the same files but different implementations. In Main you normally write e.g.
import org.mycustom.Version;
And if you included Version1/Version2 project as reference it will compile with the Version.java file from Version1/Version2 project.