first post. I am working to convert a standard JavaFX application to a Gluon project so I can re-use my code base across all the major platforms. I am still learning the Gluon framework/work-flow and thought it would be a good idea to look at an example project of similar scale and see how it was implemented in Gluon. The project I am trying to reference is this:
https://github.com/jperedadnr/Game2048FX
My problem has been the NetBeans cannot seem to find the Charm Down PlatformFactory import. In doing some digging it seems like it is no longer supported?? If that is the case is there anyway I can easily modify the code to be able to run the project and play around with it as a way to learn the Gluon ecosystem? If not are there any similar projects I can use as a reference instead? My application is a simple variation on the classic checkers game, so it is nothing too complicated. I was looking for something with a similar complexity.
While the project is a nice use case for you to try, I have to say the code at Github is pretty outdated [Disclaimer: I'm the author].
But you can still make it work easily, of course.
The Charm Down dependency:
repositories {
jcenter()
maven {
url 'https://oss.sonatype.org/content/repositories/snapshots/'
}
}
ext.CHARM_DOWN_VERSION = "0.0.3-SNAPSHOT"
is not available anymore. This is what relying on snapshots should be avoided...
So you can try to find the next available snapshot or release version, trying to use the closest version possible to avoid breaking changes with the existing repo.
So far, you can try:
ext.CHARM_DOWN_VERSION = "0.0.4-SNAPSHOT"
which is still available (see for instance Charm-down-common).
Or you can choose a release:
repositories {
jcenter()
}
ext.CHARM_DOWN_VERSION = "0.0.3"
Note that both versions are the same (see dates, both from September 2015).
But even if you have it working, the Gluon project and the platform related code are quite outdated.
I'd suggest you take a look at the current Gluon samples, and to the Charm Down library.
Related
I'm looking for possibilities for generating documentation using DocBook as part of my Maven build process. What I'm finding is everyone is suggesting docbkx-maven-plugin over Doxia. The problem is that it seems docbkx is no longer maintained or at least they've moved and left no forwarding address for where to look at the source code. According to the plugin's website the repository is on googlecode.com which of course hasn't existed for many years now. The last update I found of the plugin was back in 2016. This leads me to believe that the plugin is no longer maintained. Does anyone have any news to the contrary, or a different option for generating DocBook output during a maven build?
The source is available here: https://github.com/mimil/docbkx-tools
It does look like the project is no longer maintained, having seen no commits since 2015.
You don't actually need the plugin. If you have a working DocBook toolchain, you can use Maven to invoke it. The plugin could make certain aspects easier, but it also adds a limitation in that it only supports HTML output.
I've been searching around for a while and can't seem to find anything regarding this issue. I'm new to Java in general and for the last half a year I've been learning Maven. I use IntelliJ IDEA and I'm already used to the fact that it can autocomplete dependency coordinates (groupId, artifactId, version) if you sync the repository. It works nicely and it feels natural when you decide to add some dependency after the initial project generation.
Now I'm trying to switch to Gradle (which is a requirement on my new job) and I'm studying it. And I can't get over the first roadblock that I've encountered with it: there is no autocompletion and it even seems like IntelliJ IDEA's support for this kind of feature has degraded over time (I saw a video of old version of IDEA where there used to be a "Generate" -> "Add maven dependency" option, which I cannot find in the latest version). I even tried a bunch of plugins with names like "Gradle Dependency Helper" and non of them worked.
Are we supposed to type the whole dependency coordinates to add them to gradle build? Because that feels like a big downside of Gradle with IDEA. Or is there some well hidden feature that I missed?
You may manage Gradle dependencies in Intellij IDEA using View→Tool windows→Dependencies.
It allows to add or remove dependencies from dependencies section in your build.gradle and gives full-text search for available dependencies.
I'm relatively new to Android Studio and find myself very confused about the levels for dependencies in Gradle. Let me explain why, then I am seeking assistance with a specific issue and the broader issue of choosing dependency levels. I should mention that I am using Android Studio 3.1.3 with Gradle 4.4. My Min SDK Level is 24 and my compile level is 27).
I am doing my first experiments with Settings and have skimmed several tutorials (online and in YouTube). They all begin with the advice that you need to add a dependency for Preferences in your Gradle file. (They aren't consistent in WHICH dependency to add but I think that's because there are different approaches to doing preferences.) In any case, once you've chosen which approach you are going to take, you need to add the appropriate dependency to your build.gradle (Module app) file.
So, let's say we decide to add com.android.support:preference. According to the manual - https://developer.android.com/reference/android/support/v7/preference/Preference - the current version is v7:28.0.0-alpha1. If I add that to the Gradle file though and try to sync, Android Studio tells me I should not let the dependency be a higher level than the compile SDK level (which is 27).
So, I imitated the level that I used in other dependencies, like appcompat, and set the level to v7:27.1.1 and tried to sync again. That failed too. Apparently, no such version of the dependency exists.
Most of the tutorials I've seen are two years old and refer to dependencies that are at level 24, which I assume is going to be too low.
And that brings me to my question: How do I determine which versions of a dependency actually exist so that I can choose an appropriate level?
I read through this page on the Android developer site and I suspect you may have the syntax wrong for the dependency. The v7 should be part of the module name, not the version as I understand it.
Try:
dependencies {
implementation "com.support.android-v7:27.1.1"
}
This page makes reference to palette-v7:27.1.1 so I assume the same version exists for preference.
I have been in charge for the past 5 years of the development and the maintenance of a GWT project which consists of 6 different WebApps. The project is using GWT 1.5 and is built with ant (for either mode dev/war). These webapps are deployed on apache-tomcat, the production site run version 5.5 whereas we run (for testing) version 7.0.
To emphasize user experience, I would like to migrate the GWT version to a more recent one (of which I have no idea so far); I have read many things about migrating, regarding deprecated APIs, improvments made frome one version to another and I have still structural questions dealing with the new project layout itself.
Currently, the layout is the following:
WebXXX
-src
-net.yyy.webxxx
-common
-client
-server
-public
-Common.gwt.xml
-module1
-client
-server
-public
-module1.gwt.xml
-[...]
-test
-build
-build.xml
-buildModule1.xml
-[..]
-Dependencies(SVN_Externals)
-www
-compile-all-modules.xml
-compile-module1.xml
-WebXXXHosted.xml
-[..]
To explicit things a bit, the fodler Dependencies is a place-holder for linking Workspace sources with an external widgets library. This library is built at compile time (when building all modules or just one within an ant task) and the resulting jar is injected into the module WEB-INF/lib directory. That widget library does use gxt.1.1.1 and gwt-incubator 1.5.
Over the years, writing a new ant task for each new WebApp seemed to be the solution but now that we are also using maven, I am wondering if I must convert the project to a maven project before doing the migration or if I can skip, for now, the maven conversion.
Since I guess maven is not absolutely required and since the project includes several customized ant tasks to have it run (in dev mode), I am also wondering if I could (instead) migrate the related GWT jars in a version which is such that I won't have to rewrite all the UI though I know I will have major replacement to do and extensive tests to run.
Feel free to enlighten me about the way I could go (maven or not, the version of gwt I should migrate to, the related gxt version (if it's still relevant) to use) because I am in complete darkness !
Thanks for all,
Cheers !
Go one step at a time.
Always use the latest version (and migrate ASAP when a new version comes out). That being said, there've been reports of 2.5 and 2.5.1 having a few regressions in GWT-RPC, so if it doesn't work, try using 2.4 (but try 2.5.1 first!)
You'll have to update your GXT dependency too (I have no idea how they deal with backwards compatibility at Sencha and how much it will break your code –or not–; and again try to stay up-to-date)
gwt-incubator is deprecated for long, so be prepared to replace some of the widgets, and in the long run you'll want to totally remove that dependency.
don't move to Maven until after you upgraded GWT, unless upgrading breaks your Ant tasks too much (then try moving to Maven and then upgrading GWT; but 1.5 is a really old version so I have no idea how well it works with Maven).
Re. Maven, GWT will soon use Maven too and will provide an official plugin. Alpha versions of that plugin can be found at https://github.com/tbroyer/gwt-maven-plugin (I've received rather positive feedback for now); or you can use the gwt-maven-plugin from CodeHaus, or simply call the GWT Compiler with the exec-maven-plugin (or the antrun-maven-plugin). As for the project layout, see http://blog.ltgt.net/announcing-gwt-maven-archetypes-project, this is the layout the official GWT plugin will be based on (and again, mostly positive feedback so far).
If you are planning to do both migrate to gwt and maven, I would face first to migrate the existing project to maven. You have to be sure that all dependencies are in maven repositories or you know how to deal with local repositories. Once you have everything mavenized in modules and you can import the projects in eclipse (maybe you need an old gwt plugin) and run all tasks I would try to migrate module by module selecting the appropriate dependencies.
I think updating dependencies with maven is pretty easier than dealing with ant, but of course you could select the other way if you feel more conifrtable.
Anyway, the task of migrating a gwt application from 1.5 to 2.5.1 could be hard. First you have to know how the evolution of gwt to know which issues could come to your app (new widgets interfaces, handlers, etc).
You are depending on gwt-incubator which has been discontinued since some years ago, maybe you have a build which could work with gwt-2.5.1, but probably there are many things which dont work any more. There are some features which have been moved from incubator to gwt like cell-lists, date-picker, etc, so you have to rewrite your code using new stuff in gwt.
Your project depends on an old gxt version, they have made many changes in theirs api, and I think you have to deal with a lot of changes in your code as well.
In summary, mavenizing an ant project is not so difficult and you have plenty of information in the web, but porting a gwt app from 1.5 to 2.5.1 is not a trivial task, if you dont have a good suite of tests it could be harder, so be prepared to spend a lot of time figuring out how to replace old things and to fix issues.
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 :-)