I want to program in Java or other JVM languages like Scala, Kotlin, or Groovy. When I am programming on my projects, I only want to have import statements in my Java/Scala/Kotlin source files without the need to state the packages a second time in a Gradle/Maven build script. Instead I want to work as I would do in Python, i.e. have my import statements at the beginning of my source files and I am done.
The packages should then automatically included when I am compiling if all packages are installed in a central local package management system or otherwise get an error message telling me that I have to install a missing package. It should essentially work the same as for Python and PIP respectively.
Is a workflow like this possible preferably with Groovy or Maven?
Thanks in advance!
The closest I can think is Grape:
Grape is a JAR dependency manager embedded into Groovy. Grape lets you quickly add maven repository dependencies to your classpath, making scripting even easier. The simplest use is as simple as adding an annotation to your script:
#Grab(group='org.springframework', module='spring-orm', version='3.2.5.RELEASE')
import org.springframework.jdbc.core.JdbcTemplate
Like in this example:
#Grab('net.sourceforge.nekohtml:nekohtml:1.9.16')
def parser = new org.cyberneko.html.parsers.SAXParser()
def page = new XmlParser(parser).parse('https://news.google.com/nwshp?hl=zh-TW&tab=wn')
page.depthFirst().DIV.grep{ it.'#class'=='title' }.each {
println it.A.SPAN.text()
}
I can't judge the Groovy landscape since I don't have any experience there, but for developing Java or Scala applications this exact workflow is not possible as far as I know.
Regarding "I only want to have import statements..." I think the closest you can get is good Maven/Gradle/sbt integration in an IDE, like IntelliJ that automatically adds the desired library to your build system's configuration file when using the correct shortcut. It (at least) works for some Java libraries when you're dealing with a Maven project in IntelliJ.
And regarding your other wish to have packages automatically included when compiling: On the JVM there is the concept of the fat JAR (also called uber JAR), which is basically a JAR (Java archive) that contains all dependencies and is thus self-contained. Usually you can start the application contained in it with a single java command.
To build fat JARs you need to have the approriate plugin for your build system:
For Maven that would be the maven shade plugin, see https://maven.apache.org/plugins/maven-shade-plugin/
For sbt you can use the assembly plugin, see https://github.com/sbt/sbt-assembly
Gradle probably has something similar
A lot of Java frameworks also come with their own build plugins that make building such self-contained applications relatively simple (Spring Boot is one example, but only suitable for applications that on top of an HTTP server)
Hope this helps, althought it's not an accurate answer to your question. :)
Related
since .jar is not anymore the best format to use to distribute our JavaFX project, I'm willing to use the tool JPackage for that instead, but after reading this post : https://stackoverflow.com/a/68823040/4262407, I ended up having multiple questions, but first of all, I just wanna make sure I ve well understood the process that I should follow :
the process :
1-create a modular project
2-package the project in a .jar format
3-use the tool Jlink to create a customized run-time image (to reduce the size of the output)
4-use the tool jpackage (it takes 2 and 3 as inputs)
I'm also wondering if I can rely on Intellij artifacts to create the .jar file (the 2 step) is it better to use a specific plugin ?
The last thing that is not clear is do we need to include the dependencies in the .jar file ? since I believe they will be included in the customized run time, won't they?
If you take a look here, there is an explanation on how to create JavaFX projects starting from a template that includes Maven plugins to easily pack the application using jlink.
Doing it like this will allow you to completely rely on IntelliJ, making things much easier.
Once you have your runtime image, you can pack it with jpackage. There was already a discussion about this topic here.
And here is a fast link to the article mentioned there. The article there shows it using Gradle, but you can do the same with Maven, just use the appropriate plugin (jpackage-maven-plugin, as stated in another answer here).
Also, from what I can read in your comments, it seems that you have both modular and non-modular dependencies. In that case, you can use jdeps to achieve what you need. There is a nice article here about having mixed dependencies, that specifically uses JavaFX as an example of modular library within a non-modular application.
Just have look here https://github.com/dlemmermann/JPackageScriptFX for a tutorial with a working example. Its especially useful for non-modular projects.
I used the jpackage maven plug-in to build the native executable(https://search.maven.org/artifact/org.panteleyev/jpackage-maven-plugin).
You will first have to use maven-javafx-plugin to create a jlink runtime image(https://github.com/openjfx/javafx-maven-plugin).
You will then use that runtime image within jpackage plugin(... ).should create an executable successfully then.
The jpackage tool does not require a modular project. Though if your project is not modular then your project will be mixed due to JavaFX being modular. In that case, you'll add the JavaFX modules to the custom run-time image while telling jpackage to treat your code as non-modular (i.e. it will configure the executable to place your code on the class-path).
You can also combine steps 3 and 4 into a single step. The jpackage tool can generate the custom run-time image. It will use jlink "behind the scenes".
As for what format your code needs to be in, packaging it in a JAR file will be, in my opinion, the most straightforward. But I'm not sure that's strictly required.
Any dependencies of your application will of course need to be included with the final application. If those dependencies are modular then you can have them included via the custom run-time image. But if you want them on the class-path then you can include them the same way as your code (i.e. --input).
Note the jpackage tool has a user guide: https://docs.oracle.com/en/java/javase/16/jpackage/packaging-overview.html
I'm thinking about start using (not playing with) Clojure. Are there any useful guides? I'm not asking about lein, javac or any other 'small' manual tools. I need to know how to have Java and Clojure sources in eclipse in the same project. How to make them calling each other without compilation errors? How to configure maven? How to set up fully productive development environment? Is it even possible at the moment? What plugins may be useful? Where to start?
I have a fully working production setup with Eclipse, Maven and Clojure that is working very nicely at the moment. Hopefully it is helpful as an example of a good polyglot setup within a Java IDE.
I don't use leiningen - Nothing against lein at all - it's very nice and ideal in a pure Clojure/CLI world. But I've found that pure Maven is nicer to work with in a polyglot Java+Clojure environment with an IDE since the tool integration is so much better. Also from an ecosystem / audience / community perspective if you want people from the Java world to be able to build your source you are going to cause a lot less confusion if you just use Maven directly.
Here is my setup:
Eclipse 4.2 as main IDE
Counterclockwise Eclipse plugin - very good, takes care of REPL, Clojure editing etc.
Maven used to manage all projects (I use the built in Eclipse Maven integration mostly, but occasionally use the CLI version as well)
cljunit used to enable JUnit tests to run on Clojure parts of the project
Github / Travis CI used for SCM and Continuous integration, accessed using the built-in EGit team provider in Eclipse
In terms of actually how I manage / set up the project itself:
I configure everything with Maven, using standard Maven directory layout. Polyglot Java+Clojure Projects typically have both src/main/java and src/main/clojure
Clojure is just a Maven dependency, like any other Java library.
I make the Clojure source directories into resource directories in the Maven setup. This means that the .clj files get bundled in any jars and can be loaded / run dynamically at runtime.
I usually make the entry point on the Java side with a public static void main(...) as usual, but call quite quickly into the Clojure code. See this blog post on calling Clojure from Java.
Finally some coding tips for polyglot Java+Clojure
I find that Java is better for low level data structures, libraries and algorithms, while Clojure is better for integrating things together and "glue" code.
Clojure calling Java is usually easier / more elegant than the other way round. Also it makes sense since you generally want the dependencies to flow that way (higher level code calling lower level code)
If you make all your Java classes immutable, they play very nicely in a Clojure world with minimal effort.
Sometimes it is worth making one or more of your Java classes implement some of the Clojure interfaces, particularly clojure.lang.IFn for example. This way your Java objects can act as first class functions in Clojure code.
Here's an example project that mixes Java and Clojure source:
https://github.com/mikera/enlight
I also wrote a small library (clojure-utils) that includes some example code for calling Clojure from Java, which you may find useful.
Despite your tone about leiningen, I recommend looking at it. Leiningen supports Java compilation, so combining java and clojure sources in one project isn't a problem.
The Counterclockwise plugin, the clojure plugin for Eclipse, can work with leiningen project files (project.clj). So within Eclipse you have dependency management and java compilation all handled for you by defining the right things in project.clj, without the need to install leiningen separately or execute commands from the command line.
In the project.clj set :java-source-paths, like for example:
:java-source-paths ["src/main/java"]
In package src/main/java put a class Foo:
package main.java;
public class Foo {
public static final String value = "Michiel";
}
Somewhere in a clojure source file define this function and "Michiel" will be printed when it is called:
(defn foo
"I don't do a whole lot."
[]
(println (main.Foo/value)))
Further reading:
http://leiningen.org/
http://code.google.com/p/counterclockwise/
You could also try the framework "Funky". It will completly seperate you Clojure and Java code . Just have a look at https://github.com/windler/Funky
I am experimenting with my first GWT app that uses GIN. I am essentially mimicking the exact same source code example found in their Getting Started tutorial. At the end of that tutorial, the author mentions that you need to supply the the GWT compiler with a classpath pointing to the compiled Java binaries. The example they use for doing this is done using an Ant target.
Although I will have an automated (Ant-driven) build that also emulates this build task, I want to be able to run/debug my GWT apps from inside of Eclipse without having to kick off an Ant build.
So I ask: when running my GWT app inside Eclipse (Dev Mode), how do I configure the GIN library to point to the compiled classes? Thanks in advance!
All you should need to do is add the gin.jar (and dependencies, probably just guice.jar) to your project's classpath.
It should not be required to copy these to WEB-INF/lib/, though depending on your server setup, you may require guice.jar there, but never gin.jar.
I'm trying to learn project automation and I'm using the book Pragmatic Project Automation as a guide. It's examples are in Java so I find it easier to follow it along in Java. I don't have any experience using Java or any of its IDEs. However, I've learned some C# using Visual Studio (although I'm still a beginner).
I'm having trouble understanding some parts of setting up a Java project. I'm using Netbeans IDE 7.0 on Windows 7. With Visual Studio, I have a solution with projects underneath. With Netbeans, I appear to just have a project with directories determining the rest of the structure (and the IDE to some degree)? The equivalent to Add Reference appears to be adding a source to the Classpath. There also seems to be a degree of separation between the compiler and the IDE. I'm currently in a situation where I can compile my project just fine while the IDE tells me I still have errors (and I assume this is because I have the project set up incorrectly).
I'm basically looking for analogies that will help me better understand Java project structure.
Lots of similarities between the two languages and IDEs. I spent many years in both. For starters the equivalent to 'add reference' in VS is adding a library or jar in netbeans. In respect to a reference - a jar is pretty much the same thing as a module or .dll in VS. A jar is a compiled reference. To add a reference just go to the project menu and then properties then to the libraries menu from there you can add either pre-assembled netbeans libraries, which are collections of .jar's, or a single .jar, or even a project. Once you add a reference you can import them into your class just like you would in C#.
Netbeans doesn't really have a 'solution' as VS does. You deal with individual projects. It does however have the capability to add a project as a reference so you don't have to continually re-build the references when you change something between multiple projects. It also has project groups to group similar projects.
Lastly Apache ANT is responsible for tying everything together in the background. Netbeans creates a build.xml and build-impl.xml file in the background to tell ANT how to assemble the project into a .jar.
There are my other things to cover but I thing this answers most of your questions. Does this help?
I can't speak for NetBeans, as I use Eclipse, but you are on the right track with classpath being roughly equivalent to references in the Visual Studio world. Libraries (usually .jar files) are placed on the classpath and must be there both at compile time and runtime (you specify the classpath to the compiler at compile time, and to the JVM at runtime). The classpath can contain many different entries, and they can be anywhere in the project structure (or outside of it entirely).
Java itself doesn't impose many restrictions on your project structure, although various IDEs and build tools do. The one thing that is a universal restriction in all Java environments is that source files (and class files) are placed in a directory named after the package name. So if your package name is com.test.something, then your source files will be in SRC_DIR/com/test/something, and your class files in OUT_DIR/com/test/something (note: SRC_DIR and OUT_DIR are not special variables; each IDE will have a different way to specify those directories).
Java libraires tend to heavily build-on one-another, so at some point, you'll find that the classpath entries are too many to manage manually. Before you get there, you'll want to take a look at Apache Maven or Apache Ivy which are dependency management tools. You'll need to understand how they work (either one, not both) and how to integrate them with your IDE. If you use Eclipse and Maven, m2eclipse offers fairly complete integration between the IDE and the dependency management tool.
With Netbeans, I appear to just have a
project with directories determining
the rest of the structure (and the IDE
to some degree)?
Visual Studio dictates a particular project layout and since the compiler is so tightly integrated into the IDE there's no real concept of a build script. In contrast, Java has no such structure (although certain 'best practices' have emerged such as having a 'src' directory for source files, 'lib' for libraries, 'test' for test source, etc.) and a build script is usually required to tell the compiler were to find source files and libraries, what artefacts to produce and a miscellany of other chores (running tests, deployment, creating code metrics and so forth).
In simple cases, the IDE will take care of this for you (if you follow the convention for that particular IDE) but ultimately you will probably want to take a look at a build tool to understand what's going on behind the scenes. Apache Ant and Apache Maven are both prominent offerings. Ant is very flexible whereas Maven attempts to dictate a common layout. I suggest you investigate both and see which suits.
There also seems to be a degree of
separation between the compiler and
the IDE. I'm currently in a situation
where I can compile my project just
fine while the IDE tells me I still
have errors
If your code compiles, it is correct. The IDE is simply acting in an advisory capacity (and will highlight issues beyond compiler errors, such as warning you of potential code mistakes or bad practice).
and I assume this is because I have
the project set up incorrectly
This is a possibility although, as stated above, there are many other explanations.
I have looked for an answer for this nearly every where that I can think of, but there doesn't seem to be any way to actually SEE what Eclipse "runs" to compile the projects (as it does need the JDK installed and visible to actually build). I ask because I imported a few jars into my project, and even though I've looked through all the javac documentation, I can't seem to figure out how to mimic it quite like Eclipse does. I really, really need to be able to compile on the command line in this case - Eclipse or any other IDE just isn't what is needed.
I started to look through the Eclipse source, and although this sounds lazy, I just became overwhelmed and figured I would ask here first, hoping someone else had the same question at one point.
Eclipse JDT does not require the JDK and does not use javac - it uses it's own compiler.
You can see the classpath by reading your project .classpath file. The various builders that are used to perform build operations (Java, or whatever the project builds) are listed in the .project file. (These are also listed in the project settings.)
It is possible to invoke Eclipse to build your project in headless mode, or write Ant scripts that can be executed both with the JDK and within Eclipse, or install Maven support for internal and external building. It is also possible to configure the project builders to rely only on external tools.
Look at these two articles.
http://www.eclipse.org/articles/Article-Builders/builders.html
http://www.eclipsepluginsite.com/builders-natures-markers.html
Look at your .classpath file and start building an ANT build.xml. You need to do this to be able to have consistent builds on a build machine anyways. It is unlikely that a build server would have eclipse installed on it anyways.
Maven is also another tool that is used for builds. In our shop we use Ant.
Have a look at ant4eclipse - this project allows for generating the appropriate ant data structures for invoking <javac> from the .classpath files and a projectSet.psf file.
By using this we can use Eclipse "natively" and bend ant to conform to Eclipse. The usual approach is the other way around.