I'm struggling to put some order in my mind about SAX/DOM integration with Java. I find the information over the Internet messy. I would appreciate if someone could answer some, probably knives, simple questions.
Here's my environment:
Eclipse Oxygen.
Java 8.
Maven Project without any dependencies (is a simple console test project).
My Questions
What parsers (SAX/DOM) come packaged, if any, with Java 8? I couldn't find information over the Internet.
After deleting CLASSPATH from my environment, ensure no org.xml.sax.driver system property was set, XMLReaderFactory.createXMLReader() method still returns an object com.sun.org.apache.xerces.internal.parsers.SAXParser. Where does it come from?
Related
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.
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 :-)
Its quite a while since I started learning Java EE (I come from Rails world).
I'd like to test create a simple blog to test these:
- Hibernate, JPA
- Spring with MVC
- JSF and routing
- Struts 2
- Eclipse and local test (modify, reload, check changes)
- Tomcat, Jboss or Jetty
- An administration area (Session)
- Maven
I've a basic knowledge of each of those but as soon as I spend tons of time installing stuff and, somehow, I manage to resolve all inconveniences there is ALWAYS something that goes wrong (installation, tutorial obsolete, should I work with Spring IDE, MyEclipse, Jboss Application Server or regular Eclipse?, tons of random errors, each tutorial asking for random dependencies, each showcase).
QUESTION
How do you create quickly a startup project with these components?
You go with some Maven archetype? If so which one?
What I'd like is something I can download or build equipped out of the box with all above mentioned components. To name a few:
- railswizard.org, youvegotrails.com, railsboost.com/templates/new
SIDE QUESTION
Currently I'm following this great series, can you suggest some more like this:
- http://www.youtube.com/user/koushks?feature=gb_p13n_ch_rec
All the above components in a single project? That makes no sense; Spring MVC, Struts 2, and JSF would rarely be combined in the same project.
Each web framework has demo applications, what's wrong with those? There are archetypes for at least some combinations, although I'm not sure it's not better to put them together yourself.
Without knowing what kind of issues/errors you're getting, it's impossible to help. Maven should be taking care of most/all dependency issues. You shouldn't be spending much time installing anything by hand except maybe an app container.
IMO you're better off asking specific, actionable questions, and start with each specific technology and build up an application, rather than trying to integrate everything at once--a sure recipe for frustration.
For starting with a simple Java EE application, a good point to start is just downloading a Java EE 6 implementation.
Those are offered by various parties, which might be confusing at first. It's however just like there isn't the One and Only C compiler, but there are many and they all compile the same standard C.
For Java EE 6, obvious choices are GlassFish 3.1.2, JBoss AS 7.1, TomEE. (just pick one, at this stage it doesn't matter much which one you'll use).
Java EE 6 is a full stack solution. It's a single download and you don't necessarily need to install any other libraries. It comes with an MVC framework (JSF), an ORM solution (JPA), dependency injection (CDI), business logic support (EJB) and then some.
As for the IDE, NetBeans has a particular good default integration for GlassFish (can even be downloaded as one bundle), but for Eclipse it's not that difficult either. You need to download the Java EE edition of Eclipse and after starting it, go to Help -> Eclipse Marketplace, search for "GlassFish" and install the "GlassFish Server Plugin".
See also Minimal 3-tier Java EE app, without any XML config for a very minimal example to get started and JSF 2.0 tutorial with Eclipse and Glassfish for a very detailed one including instructions how to exactly setup the IDE.
What I'd like is something I can download or build equipped out of the box with all above mentioned components. To name a few:
http://appfuse.org/display/APF/Home
Appfuse will take you through the initial setup of a maven built spring based web application with hibernate included.
If you come from the rails world you might also look into Spring Roo which tries to borrow from Ruby i'm told. The primary focus of roo is to stand up all of the technology you've listed above quickly.
I have been assigned a job to compile an old Websphere(WAS4) project, so we can find out which parts of it need to be changed for the project upgrating( to WAS7).
But when I was trying to fix the jar errors, wesphere.jar is missing!! And WAS7 installation path never hava this jar anymore, searching google failed. And I don't like to install older WAS again to just get this jar.
please anybody can help with this, providing an WAS4 version webspere.jar???
TKX in advance!
The jar file itself isn't important, the classes within it are. I don't recall what was in websphere.jar, but there's a good chance that what was is now in j2ee.jar. In fact, if your code isn't using any WebSphere-specific extensions, there's a good chance j2ee.jar is the only jar from WebSphere that you'll need for compiling.
But you should be able to see what specific classes are being complained about by the compiler and if necessary search for those by opening the jar files in like WinZip.
(Keep in mind that the larger changes are the changes to J2EE and Servlet specification levels.)