This is my first time publishing Scala library into maven central. I follow this tutorial from Scala docs. After I prepare everything, I want to publish my library in SBT shell with command publishSigned, then I get the error about "gpg: signing failed: inappropriate ioctl for device". I did google and try to find the solutions, Here is some sources I find from StackOverflow and ArchLinux. I try to add $ export GPG_TTY=$(tty) into my ~/.bash_profile , but It does not work for me. It looks like sbt shell does not able to get gpg credentials in anyway.
How do I fix it? Thanks for any help.
I fixed this by downloading GPG Suite, and then typing passphrase manually
I am working on a team task. When instructed by a piece of documentation to run grunt fix scss I did so, and I received the following message:
jit-grunt: Plugin for the "fix" task not found. If you have installed
the plugin already, please setting the static mapping. See
https://github.com/shootaroo/jit-grunt#static-mappings
Warning: Task "fix" failed. Use --force to continue.
The problem is that I have no idea whether the plugin they mention is installed. What command would I need to run in order to install this plugin?
The problem was that I was running grunt fix scss rather than grunt fix-scss (with a hyphen).
Once I did the latter, I got more meaningful output.
I install Cygnus from RPM repository like this and now i dont know how continue.
I try continue whit this section and i got the following error:
bash: APACHE_FLUME_HOME/bin/cygnus-flume-ng: No such file or directory
I am really confused about documentation, because i restart 3 times at start when i try to use docker image, the image got so much errors.
You need java, maven and Flume correctly installed before starting.
export APACHE_FLUME_HOME_BIN=/usr/local/flume to your shell
I recommend following the install from source, which guide you through all the steps.
For docker start with the cygnus-common Dockerfile which uses centos6 as base.
Lately I have challenged myself to build the Eclipse IDE from the source code. This will open an opportunity to start playing around with the code, and make some changes.
I found the following tutorial to guide me through the procedure: http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html
Especially chapter 13 of that Tutorial is helpful. Apparently I need to have the following software installed on my (Windows) machine:
Git
Maven Version 3.3.1 (make sure that the bin folder where you extract Maven is added to the PATH)
Oracle 1.8 JDK or higher
I have all this software on my desktop - so I'm ready to go. I start by cloning the newest Eclipse repository and it's submodules via Git to some folder on my machine:
git clone -b master --recursive git://git.eclipse.org/gitroot/platform/eclipse.platform.releng.aggregator.git
This takes a couple of minutes. Maybe half an hour at most. Eureka - the folder is now pretty full with the Eclipse source code! The vogella tutorial proceeds with the actual build command. I open the command prompt in Windows and surf (cd..) to the right spot. Then I type the command:
mvn clean verify
I first got some errors. But thanks to the StackOverflow community, they are solved now. Please refer to this link for more info: https://stackoverflow.com/questions/37645180/building-the-eclipse-ide-from-scratch
Eclipse builds. And it builds. And it keeps building for hours. After many hours, I get the message that the build has finished. I'm amazed it took such a long time, since my computer is quite a beast:
> CPU: Intel Core i7-4790K CPU #4.00GHz
> RAM: 16.0GB
> System type: 64-bit OS
> Windows 10 Home
Anyway, after the build has finished, the JUnit testing automatically starts. I have no option to skip it. I wait for some more hours, until I really need to stop the system and go home. I close the command prompt - knowing that I interrupt the JUnit testing. But who cares :-).
I check my filesystem, and cannot find the files about which the Vogella tutorial speaks:
eclipse.platform.releng.tychoeclipsebuilder/sdk/target/products/*
Help.. was the whole build procedure done for nothing? I want to redo the build, but is there a way to skip those JUnit testings?
EDIT: I followed the advice of Mr. Gerold Broser and added the -DskipTests flag to the mvn clean verify command. I believe that Eclipse is now building without doing all the JUnit testing. Nevertheless, I still feel like the build takes an eternity. I'm now waiting for 4 hours. Is this normal? Are there ways to tell the maven build tool that it can use all 4 CPU cores?
EDIT: The Eclipse build has finally stopped. Unfortunately, it is no big success. I get a very lengthy error message. The build has failed. I've opened up another StackOverflow post to get some help:
https://stackoverflow.com/questions/37662645/building-eclipse-from-scratch-build-failure
Hope you can help me out.
See Maven Surefire Plugin / Skipping Tests:
You can also skip the tests via the command line by executing the following command:
mvn ... -DskipTests
I have downloaded a project which uses sbt as its build system and I want to build it. You'd think it would be as simple as typing "sbt" or something, but no.
I thought I'd add a question for this because it can take literally hours to figure this out on your own. I'm not joking.
tl;dr:
sbt compile
If you want to run it:
sbt run
To see what other targets are available:
sbt tasks
To get some (other) help, but mostly targeted at commands typed from the sbt console (ie, running sbt without parameters):
sbt help
This all assumes sbt version >= 0.10.0. To see what version of sbt is in use, do:
grep sbt.version project/build.properties
If there's no such file, and there's a file with extension ".sbt" on the base directory (not the project directory), then it's >= 0.10.0. Of course, if the grep works, it should tell you the version.
First, you'll want to use sbt-extras, because that automatically downloads and uses the right version of sbt. Trying to use the wrong version of sbt (newer or older than what the project you're trying to build says it requires) won't necessarily work, and may cause strange errors.
Run it:
~/path/to/sbt-extras/sbt
Wait for it to start up and download everything. If you need to use an authenticated proxy, you'll need to edit the script to specify the username and password for the proxy.
Check the version of Scala that sbt thinks it needs to build against (at the end of the output, if everything worked). If this is OK, fine, you don't need to do anything. If it isn't, you can temporarily specify a version explicitly with ++, e.g.:
++2.8.1
(If you want to make this permanent, you can edit the build definition files, but as that involves making a change to files under version control, that might not be what you want to do.)
Now, if you are using an older version of sbt, don't skip the next step! You could get strange errors if you do.
update
Now you can build and test what you've built:
test
If you get an error "Filename too long", this is not an sbt-specific problem, it's a scala problem, which most frequently affects Ubuntu users (technically, for Unbuntu users it's generally related to home directories encrypted with encfs). If you are using Scala >= 2.9, edit the build to use the scalac command-line option that allows you to specify a maximum filename length. Otherwise, if you are on Linux, you can redirect the build to /dev/shm or /tmp, by running these commands in a shell prompt (don't background sbt with CTRL+Z on Unix, because it may appear to stop working properly):
rm -rf target
ln -s /dev/shm target
(you may have to execute these commands in project/build instead or as well.)
Actually, it's probably better, and may even be more secure, to create a subdirectory of /dev/shm or /tmp and use that instead.
The compilation result should appear in target. You might then want to run it, if it's something you can run:
run
If everything looks OK, you can optionally publish the result locally so that the result can then be picked up automatically by other sbt builds:
publish-local
I don't think I could explain it better that the Getting Started Guide could. Please read the first 6 parts of it, which shouldn't too long time, to get it up and running.