I'm a casual Scala user; I use the Eclipse-based Scala IDE, and I have never needed to know maven or sbt. I'd like to learn scalafx, but all the instructions are for maven. In the Scala IDE, Scala doesn't recognize my imports. Can someone tell me how to have the IDE recognize the jar file?
I have
Scala IDE 4.2.0-vfinal-2015-09-25T11:10:29Z-Typesafe
scalafx_2.12.0-M3-8.0.60-R9.jar
JavaSE 1.8
Scala Library container 2.11.7
I tried adding the scalafx jar to my Java build path (Project->Properties doesn't have a Scala build path), and that didn't work, so I don't know what else to try.
Thank in advance!
// ----- Not an answer, too long for a comment, sorry -----
I appreciate the fact that, were I a serious Scala developer, I should learn Maven and SBT. But I'm not.
For the last several years I have taught a course in "Programming Paradigms." This semester I have taught Prolog, Clojure, Haskell, Elm, and a bit of Forth and REBOL. As in the past, I'm ending with Scala, because I think it brings together a lot of the ideas in other languages, and would be a worthy successor to Java. From what I have read, scalafx looks easy to use, and it would have been nice to have the last assignment be a GUI assignment using scalafx.
For any programming language, external factors--IDEs, make equivalents, test frameworks, support groups, etc.--are at least as important as the language itself. Given the amount of material already in the course, I explicitly do not cover any of these external factors, for any of the languages.
Since installing scalafx apparently is not as simple as adding a jar file to Eclipse (which my students already use), in my situation it is simply not worthwhile learning SBT and devoting additional class time to teaching it.
Maybe next year scalafx--or, I guess, the Scala IDE--will have matured to the point that I can use it in my course.
Thanks to everyone for clarifying the situation.
This may not be the answer that you wanted, but I would recommend that you go with either Maven or SBT - preferably the latter, as it is targeted at Scala and Scala users. The reason for this is quite simple: both systems will manage your dependencies automatically, in a very simple way.
If you decide to manage dependencies manually, then—sooner or later—you're going to be heading for a world of pain. For example, ScalaFX may have its own dependencies, which you would have to download and install on your class path, and they may have their own dependencies, etc, etc.
Learning SBT can be a challenge, but it's also very straightforward to do simple projects. For example, the following SBT file (copy to a file called build.sbt in your project's root directory) is the minimum for a ScalaFX application:
name := "myproject"
version := "0.1-SNAPSHOT"
scalaVersion := "2.11.7"
libraryDependencies += "org.scalafx" %% "scalafx" % "8.0.60-R9"
Just make sure that you're using an up-to-date version of Java 8 (you'll need ScalaFX 2 if you're using Java 7).
Also, you might want to try JetBrain's free community edition of IntelliJ IDEA, with the Scala plugin, as an alternative to Eclipse. IntelliJ supports Scala and SBT very nicely indeed.
UPDATE: Also, I just noticed that you have the Scala 2.12 version of ScalaFX, but you're using the Scala 2.11 compiler. Unfortunately, each version of the compiler requires a matching copy of Scala library code. This is yet another reason for using SBT. :-)
I have been using ScalaFX with students for about a year now both from command line and inside of Eclipse. I use neither sbt nor Maven for that work to keep things simpler for the students. I built a JAR file, much like the one that you have and either use -cp from the command line or add it to the build path (as an external JAR) in Eclipse. Both approaches have worked fine for me. I create and object and have it extend scalafx.application.JFXApp. That runs and pops up a window. It would help to know more about how it isn't working. Does it not compile because elements of ScalaX aren't being found, or does it not run after the compile?
I will also note that at the time of writing this answer, ScalaFX does not yet work for Scala 2.12, which is at the M4 stage.
Related
So I have been struggling all afternoon with getting some Gradle build to work for a Kotlin multiplatform project that involves an ANTLR grammar. What I'm trying to do is to have a parser generated by ANTLR from a shared grammar for both a Kotlin (or Java if that doesn't work) and JavaScript target. Based on this I'd like to write some library around the parser that can be used from the JVM and JavaScript.
So I have set up a Kotlin multi-platform project because that seemed like a nice way of killing two birds with one stone (here is a repo https://github.com/derkork/project.txt). I created a source set commonAntlr where I placed the grammar file under commonAntlr/antlr/project_txt.g4. According to the documentation of the ANTLR plugin this is how stuff should be set up. I also apply the antlr plugin at the top (here is the build.gradle.kts - https://github.com/derkork/project.txt/blob/master/build.gradle.kts).
Now I run gradle build in the hopes that the ANTLR plugin will at least try to generate some nice Java code for me from the grammar using the default settings. Alas, it does not. The ANTLR plugin does not even get started, which is what I can tell from the output. The build later fails with some obscure JavaScript problem, but that looks unrelated and I'd like to skip over it for now.
Now my Gradle-foo isn't exactly strong (I have only used it in extremely simple projects, most of my experience is in Maven), and I have the distinct feeling I'm missing something here. However the documentation of the plugin just says
To use the ANTLR plugin, include the following in your build script:
plugins {
antlr
}
Which I did. Since I get zero output, I have a feeling that I need to do a bit more for this to work. I have read a lot of the Gradle documentation up and down to find out how plugins work in general and I found that they add tasks to the build and also add some dependencies so that tasks are invoked when you try to build certain things. However I don't really understand how plugins work together with source sets and how you can tell Gradle "would you please run the generateGrammarSource task for this source set" (or if it even works like this).
So if some of the Gradle gods could enlighten me on this, this would be much appreciated :)
I have met a similar issue: https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin/tree/feature/parser
My solution -- which is still a work in progress -- consists in decomposing the problem.
I reasonable solution in my opinion is to create a Kotlin/JVM project (say parser-jvm) where to put the generated Java code + any JVM specific facility, and a Kotlin/JS project where to put the generated JS code + any JS specific facility (say parser-js). The next step is to create a Kotlin/MPP (say parser-common) project whose JVM implementation depends on parser-jvm and whose JS implementation depends on parser-js.
My approach is actually working for JVM while I'm experiencing some issues for JS, which are mostly caused by this issue.
The main drawback of this approach is that some Gradle coding is required to setup ANTLR with Kotlin/JS. I already faced this problem in my build.gradle and I'm quite satisfied with the result and the overall architecture of the project. However, I believe that my proposal is far less troublesome than configuring a Kotlin/MPP project to work with ANTLR.
I am investigating possible frameworks for the future web-app I am tasked of building and Play framework 2.3 is pretty much sitting atop the list - however, I haven't used it until now (had used Spring and Maven in another life) and I have a particular requirement on the app itself so I wanted to hear advice/thoughts from people who have used Play so far (the language used will be Java 8).
The web-app consists of modules, some of which are stand-alone units that should be built as a jars (so that they can be accessed from command-line as a part of, say, batch script) as well as being built to function within the full-blown web-app.
Now, I've previously built apps with maven and I could imagine a way to do it with it but Play comes with its own build/dependency management tool (SBT) which I am unfamiliar with and don't know the capabilities of (is this even possible to achieve with SBT? How difficult would it be?).
That being said, I have done some cursory research on the subject and I know there is play2-maven-plugin, however the examples on the homepage deal with Scala (which I, as said above, unfortunately can't use).
What's certain is that I'd definitely like to escape from any "bridging" between SBT and maven - I wouldn't want to maintain two build systems and reconcile the differences between them together, that seems nightmarish.
Lastly, I've found in this SO thread, using maven with Play 2.3 may not even be an option (SBT apparently does somehow use Maven dependencies under the hood). After all, Play was conceived as partial departure from Java EE practices so it doesn't surprise me Maven is not natively supported. Also, Play integration with Maven proved to be troublesome.
I have no objection towards learning SBT or using just maven (if that's possible/advisable) - any of these approaches I am fine with, it's just the capabilities of SBT I am unfamiliar with (especially considering the requirement from above). Mixing SBT and maven seems frankly a bit scary and documentation on building Play with SBT seems scarce at this point.
Should I go with SBT or maven? What tutorials/docs would you recommend? Should I use Activator for getting to know SBT?
NOTE I was almost to flag the question as unclear what you're asking, but at the very end of it found the real questions I'm going to answer here.
Should I go with SBT or maven?
SBT or even better Typesafe Activator. Install it on your computer, and execute activator new myNewCoolPlayJava8App play-java to get started with Play and Java.
Apache Maven might be a viable option, but don't think it's going to be a time-saver (you'll be spending quite some time to get the configuration working).
What tutorials/docs would you recommend?
The official web site of Play Framework is enough to get started with the stack (and don't get stuck) - https://www.playframework.com/documentation. I very often use it and found it very informative. When I need a bit more in-depth information I use Google or StackOverflow (under playframework).
Should I use Activator for getting to know SBT?
No. SBT can live without Activator, but no vice versa. SBT's the foundation for Activator. See https://www.playframework.com/documentation/2.3.x/Build:
The Play build system uses sbt, a high-performance integrated build
for Scala and Java projects. Using sbt as our build tool brings
certain requirements to play which are explained on this page.
And from the Activator's docs (just at the very bottom of the page):
Activator applications use sbt under the covers. This means that
anything you can do in sbt you can do with an application in
Activator. For instance, sbt plugins can easily be added to
applications in Activator just like they would normally be added.
I'm a bit surprised at the sheer number of articles / blogs / questions / answers about Clojure mentioning Maven.
In about ten years working as a Java dev, working on both desktop apps and webapps, I've never ever used Maven once (typically --and that's a personal opinion but I know some people do think the same-- the projects I've seen using Maven where including the "kitchen sink" whereas the ones built with a more "controlled" build process where way "cleaner" and producing smaller jars, faster build time, etc.).
Is Maven a requirement when you want to build a Clojure app?
Is Maven mandatory when you want to use Leiningen? For example, can I add external jars as dependencies to a leiningen project "manually", without needing Maven?
I think my question boils down to this: can you, in the Clojure/JVM world get away without ever using Maven, just like you can build, test, package and ship both Java desktop, webapps and Android apps without ever needing Maven?
Short answer: No. Clojure's just a jar and you can use it as "raw" as you like, just like any other Java library.
Longer answer: Maven's not a requirement, but the tooling around Clojure, especially Leiningen, is highly Maven-aligned so your life will be easier if you just submit to Maven's will. But, with a little work, it's not that hard to get along without Maven. At work, I use a mix of Leiningen and our existing Ant/Ivy-based build infrastructure. I use Ant to resolve dependencies (from our curated internal repo) and then use a hack of Leiningen's :resource-paths to get it to pick up the non-Maven jars. At some point I'll make a true plugin to do this stuff, but it's been working fine for me so far.
Also, if you're an Eclipse person and use CounterClockwise, you can treat your project like any other Java project in Eclipse, managing the classpath manually. It just happens that you've got some Clojure code in there as well.
Of course, the drawback in either approach is that if you want to grab something that's available from either Maven central or Clojars, you'll either have to set up some kind of mirror for your infrastructure, or manually pull down the transitive dependencies and add them to your project.
You do not have to use maven, or leiningen, for that matter. You can run the clojure REPL with
java -jar clojure-1.3.0.jar
and it will work just fine. I know where you're coming from, because a year ago, I was in the same boat as you. never used maven, seen a couple of less than great projects that used it poorly, and generally distrusted maven. Ant+ivy works great, who needs maven?
As a result of using leiningen, and starting a new job where we have a very well setup maven config, I've changed my tune completely; I now think maven is great, and far prefer it to ant, which I've used for a long time.
Specifically with clojure, some advantages of leiningen are:
automagic project scaffolding: "lein new" sets up a new project for you. convention is important, it helps other developers understand your project and quickly ramp up on it.
dependency and plugin management. adding a dependency is trivial, and there isn't a great way that I am aware of to do non-maven dependency management that is tightly integrated with clojure.
"lein repl" sets up your classpath and everything correctly, so you don't have to fool with it, you can just start and run a REPL.
artifact creation: building a fat jar (lein uberjar) is straightforward, and already set up for you.
So, while it's definitely possible to use clojure without leiningen, I honestly don't see why you would want to. There are too many niceities for day to day development not to use it, in my opinion.
regarding "Is Maven mandatory when you want to use Leiningen?"
leiningen uses and wraps Maven so you can't truly avoid it, though you don't ever need to touch any XML
Maven is not mandatory for Clojure as others have rightly pointed out.
However, I would like to encourage you to embrace Maven (either directly or via leiningen). It has some big advantages in the Clojure world:
You will be more productive in the long run - once you've got it set up, it is pretty impressive to see a complex build, test and deployment execute in a single command. Do you really want to be manually setting classpaths, downloading dependencies, incrementing version numbers, uploading to FTP sites etc.?
One of the biggest advantages of using Clojure on the JVM is access to the Java library ecosystem. Maven is the tool of choice for automatically managing dependencies on Java libraries. Nearly everything you are likely to need will be in either the Maven Central or Clojars repositories.
Clojure tends to have small focused libraries - this is good because they are "simple" and you can pick and choose the functionality you like. At the same time, it also means that you are likely to have numerically more library dependencies. Hence a build management system is going to be more useful.
You can make Maven builds as "lean" as you like. Obviously you can pull in every dependency under the sun if you like, but you can also create very lean jars by excluding the unnecessary cruft. That's your choice.
It is the de-facto standard in the Clojure world. If nothing else, using it means that you will be able to collaborate with others more easily.
P.S. Like you, I didn't really see the point of Maven 5 years ago. Then I gave it a go and saw how powerful it could be for my workflow. Now I'm a convert :-)
I am pretty new to Java and Maven and today was studying about maven, how to Mavenize a java app, how to make it good for EClipse, etc... so now I have a question: when we want to write a Java and we know that we want to use Maven too, then we start writing application and creating out directory structure with the layout that Maven likes it? or we just write our app and at the end we mavenize it? Where do we start from when we want to create a java app from beginning and we want it to be mavenized too.
Use Maven from the beginning. Why write in a different structure and convert it again at the end, while you can do it in correct way from start? If you don't use Maven from the start, what build tools you will use then? Ant? I don't see any gain in productivity in such approach.
As Adrian said, you should definitely use Maven since the beggining.
One of its main value is to guide you on "the right way". I should say "The right Maven way". It's sometimes very restrictive, but it's the main advantage : if you do like Maven is waiting for, you are probably on the way that every community or big project do.
If you start your project "by yourself", you may forgot or miss something that will trouble you. For instance, main java sources are expected to be in src/main/java. Most of the plugin use the variable sourceDirectory to bind it ... but you may have to redefine this variable many times for plugins.
Another instance, and quite often confusing, is the multi module project. If you have 2 or more project that are binded (in their life cycle), you should set up a multi module project. If you don't, you will face of code or action duplication (2 tags, 2 build, 2 deployement, etc...).
So, in order to give you a straight answer :
read http://www.sonatype.com/books/mvnref-book/reference/
use the more appropriate archetype to build your project
if you create it under command line (not with an IDE), import it
then work :)
What I'm saying will appear you more and more clear using Maven :).
See Why does Maven have such a bad rep? to better understand why :)
I recently asked about a maven like tool for other languages but there hasn't been any responses (except for a few upvotes :). Given that, I've decided that maybe using Maven is good, but I'd have to write my own plugins to do simple things
This gives rise to a number of issues, and I'd like to hear about solutions that people are using in their daily process:
running other build/release systems and mostly use Maven for packaging/dependency management? (msbuild, vcbuild, cmake, setuptools)
working directly with other languages:
The native-archive-plugin supports C/C++, but does it integrate with visual studio?
Are there other plugins for more langugages, that I've missed?
how hard is it to write your own plugin for this?
Question:
What is your recommended approach for managing non-Java languages and artefacts with Maven?
I'm currenctly using maven-scala-plugin and it work just great. I only put my sources to src/main/scala instead of java and bind scala:compile goal to compile phase and that's it. But scala is very close to java, so the issues with c++ might arise.