I've just started using an sbt plugin for packaging JavaFx/ScalaFx applications sbt-javafx. This under Java 7.
While the plugin seems to work pretty well, it is not able to properly package multi-module project. A workaround they have found is to use exportsJars := true in all the modules on which the JavaFX modules depends on.
I also have IntelliJ IDEA that can produce a JavaFX application for me, though that would break the automated build. I'd very much like to have the executable automated.
I need to understand the broad implication of that parameter on my sbt build. Why is the setting needed to be true?
Here is the help definition:
Determines whether the exported classpath for this project contains classes (false) or a packaged jar (true).
It sounds like by default it's false. Why?
p.s. If someone has a cleaner solution to package JavaFX/ScalaFX applications using sbt, please feel free to share.
Related
I have a jar that works on Java 8.
I would like to create a new jar, that is going to be Multi-Release JAR but empty, just with 'patched' classes in META-INF/versions.
I would like to have a separate jar, so people can include it on Java9, otherwise, they use the default one. Why? Because so many tools are not yet prepared for Java9 MR-Jars.
Would this be possible? Would Java9 MR-Jar override classes from others jars?
Why?
The idea behind Multi-Release jars is that they provide simple patching. In my humble opinion, the way MR jars works is not satisfying.
There are two reasons why I can't make 2 separate Jars:
try to make cross-compile source base that works with Java8 and Java9. You would end up with folders like java, java8 and java9... and then have the build produce two jars, two poms... Yeah, good luck.
Imagine that I even build a library for java9. What about transient dependencies? That would mean that all other libraries that uses mine, would need to have jre8 version that depends on my jre8 version. Just because there is Java9 version!
Here is the story:
My A is a Java library built on Java8 but packaged as Multi-Release Jar which means it contains additional classes for when jar is run on Java9. Additional classes are built separately on JDK9 and I copied them manually (yeah, I know, but it works for now).
Unfortunately, some tools and servers (Jetty) are not aware of MR Jars and this makes them NOT working.
For that reason, I have A-jre8 version of my library, that comes without any extra classes, so servers can use it.
However, if user is using library B that depends on my A, he will still get the MRJar version of A and this will fail again. I want to be able to prevent this somehow. And I can't say to B: hey, could you make B-jre8?
Possible solution
JAR is just about packaging!
Allow the separate jar to patch existing jar.
In my case, I would just include A.jar9 and Java would consider A.jar and A.jar9 together as a package. No need for META-INF/versions. Very clean. And, best of all, it would help in situations like above! If run on Java8, the jar9 jar would make no difference; if run on Java9 the jar9 jar would patch the jar with the same name. Simple as that. No transitive dependency hell.
Rename classes in META-INF/versions.
Common Oracle, have you ever heard about the classpath scanning? Could you at least rename the classes in versions to e.g. *.class9 so not to be caught by existing classpath scanners.
As it is today (Java v9.0.4) - no.
We have custom SBT task which has a dependency (addSbtPlugin). But this plugin is not actually used for compilation and testing, though SBT tries to resolve dependency immediately.
Is is possible to make SBT resolve this dependency only when the particular task is started?
I think this is not possible. If I understood you correctly, what you are asking is similar to "is it possible to resolve a library dependency only when I run the code that depends on it?". If your task depends on the plugin (or is introduced by it), that dependency has to be resolved when the project is loading.
On another note, if this plugin is not related to the project itself and you don't want to force other maintainers to use it, it's a good idea to add it to your global config (which will affect only you and work for all sbt projects on your computer):
place addSbtPlugin in ~/.sbt/1.0/plugins/
if that plugin needs any settings, you can add them to ~/.sbt/1.0/global.sbt
(substitute the version, if you are using older sbt)
I just started to work on a large project that uses SBT for building. I got a new computer with Java 8 installed, but the rest of the team still uses Java 7. That's not a problem as far as the code goes because we're all set to generate v7 byte-code.
The problems arise when attempting to publishing the project using the publishLocal action. Please keep in mind though that I am very new to SBT and some things I say/assume may not be accurate.
We use sbt 0.13. When I run the command sbt publishLocal, it runs the doc action, which in turn runs javadoc to generate the documentation. Since I have java 1.8 installed, it uses the corresponding version of javadoc, which let's be honest is a real pain in the neck, complaining about every single missing #return or #param, self-closing elements (e.g. "<p/>") and such, and returning a non-zero value because of this, thus making the publication fail. However, as I mentioned, the project is fairly big and, although it would be better to complete the javadoc documentation, it's not feasible at the moment.
Luckily, javadoc 8 provides an option do disable the pedantry: -Xdoclint:none will make it quiet about pretty much anything, allowing me to run the publish action by adding it to the javacOptions.
However, as I said, the other team members are still using java 7, and, unfortunately, javadoc 7 does not support that option, so if I push the build.sbt file with this option it will fail on other machines.
So now I'm wondering what I can do. The way I see it, there's a number of options, none of which seems "simple enough" to fix that stupid problem:
downgrade locally to java 7 (not a big fan of having two concurrent versions lying around)
have all other team members upgrade to java 8 (pain for them)
fix all javadoc problems in the whole project (pain for everyone)
Hopefully, there's another option I'm missing that would allow me, for instance, to set the javadoc options based on the java version? Or anything else that doesn't require touching anything else than the build.sbt file...
Thanks!
David
Yes, you can set the Javadoc options based on the Java version:
javacOptions in Compile ++=
sys.props("java.version").split('.') match {
case Array("1", n, _*) if n.toInt <= 7 =>
Seq()
case _ =>
Seq("-Xdoclint:none")
}
I and my team have built up an android library project. it is built up on eclipse but we are using ant to build it. Presently we aren't using gradle. I have a roboelectric with dependencies jar file instead. But when I use this, while running the unit tests, the following error comes up
WARNING: multiple versions of ant detected in path for junit
[junit] jar:file:/Users/prateekarora/Desktop/eclipse/plugins/org.apache.ant_1.9.2.v201404171502/lib/ant.jar!/org/apache/tools/ant/Project.class
[junit] and jar:file:/Users/prateekarora/trunk/client/android/MCCMobileClient/test2/libs/robolectric-2.3-with-dependencies.jar!/org/apache/tools/ant/Project.class
When I remove the apache ant from eclipse's plugin folder, this stops working.
Can Anybody explain why this is happening?
Also, is it necessary to use roboelectric with gradle? If no, where can I find the roboelectric's jar files with/without dependencies?
It is not necessary to use gradle with robolectric. It is just about running specified java class (from junit) with proper classpath (including you source, test code and dependencies). Fixing your case is not something that is easy to make over stackoverflow (it will be some challenge even if you sit behind same computer).
Here are possible solutions:
Migrate your project build to the gradle
Keep using ant but move from dependency management from manuals jars to ivy
Keep using ant and manual jars dependency, but try to get robolectric.jar with all dependencies except ant one
The first one option is the easiest option as for me. It will require to change mindset a bit but this is officially only one supported build tool by Google as well there are a lot of examples and people that could help.
The second one also require you to learn how to use new tool. As well there less examples about ivy usage especially in android projects.
The third one will require to write custom script that removes ant from jar file or to rebuild robolectric-all.jar without one (ant) dependency. This will require to dive into maven build tool learning
In working on larger Actionscript/Flash projects, I've started to really feel the need for some kind of "make" system, but I haven't found it yet. Does anyone know if it exists?
Required features:
Ability to associate SWCs with their source code and/or FLAs i.e. "this swc is compiled from this source"
Ability to mark my current project as depending on these SWCs (either as compile-time or runtime libraries)
A single, big shiny button, that when pressed does the following:
Checks to see if any of the source files have changed, and if so, recompiles their associated SWCs
Recompiles and relinks the main .swf, if necessary
Runs the main .swf
Have yet to find a way to get something like FlashDevelop to do this (but I don't know it well enough to be sure). Support for both code and FLA sources is preferred.
You are looking for http://projectsprouts.org/ which is based on Rake the Ruby version of Make. It can do all of that stuff and much more.
If you have Ruby and RubiGems installed which I think are installed by default on Macs you can install it by typing this into your command line.
sudo gem install Sprout
It will take a while because it installs many things. After this is all set you can create a project like this.
sprout -n as3 ProjectName
and then build it with this,
rake deploy
It manges things based on the runtime they are created for, this project was created for as3 but all of the other types of projects also. The build scripts are all writen in Ruby and can be modified to involve more complex multi-step compiles pretty simply. It also has a bunch of generators so that classes automaticly have unit test that are associated with them and many other features.
Might be a stupid suggestion, but if you want make, why not just use "make"? You can use it for any language by defining the right rules.
Apart from that, I've seen a lot of Flex/Actionscript projects use Apache ant, an XML based build system.
As said by wump; why not use Make?
There are some ANT scripts included in the Flex SDK, so you could explore and expand those. I've also spoken to people who use Maven and Cruise Control for automated build process.
Here is some info on Maven Flex: http://code.google.com/p/flex-mojos/
And some info on Cruise Control w/ Flex: http://www.eyefodder.com/blog/2006/05/continuous_integration_with_fl_5.shtml
Well, there are several options. One I would recommend is the Maven plugin for Flex flex-mojos, now maintained on the Sonotype site. If Maven isn't your cup of tea, they do have an Ant plugin, I don't know if NAnt can call Java Ant tasks directly or not. The third is the most complicated, but Adobe does include an OEM version of the compiler, I believe it comes by default with the SDK download. This is the one I used in the Maven plugin I developed for my company. The reason we didn't use the flex-mojos one basically boils down to a...disagreement about the "Maven way" of one project = one artifact. Their interpretation is that 1 SWF file is one artifact, so is one Maven project. My definition for my project is that all 80+ modules, each a SWF file, are no different than JSPs, all bundled in the same WAR file. So I've got one project with a LOT of modules and 1 maven pom.
You could check out Antpile which according to said link "is a collection of Ant Scripts which cover everything from building a SWF, SWC, AIR, Android and even Unit Testing."