On a Windows machine I've been using Groovy in Gradle projects in Eclipse for some time now. Now I'm trying to configure for a Linux machine. (Linux Mint MATE). uname -a gives this:
Linux mike-Latitude-E6410 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2
15:58:04 UTC 2016 i686 i686 i686 GNU/Linux
Eclipse Oxygen. Installed Groovy (2.4.15) using this link: http://dist.springsource.org/snapshot/GRECLIPSE/e4.7/
Installed Gradle (4.7) using Buildship Gradle Integration 2.0.
Then I put this line in build.gradle:
compile group: 'org.codehaus.groovy', name: 'groovy-all', version: '2.4.15'
I make a new "source directory" under the project: src/test/groovy.
I make a new file under that: "Test.groovy".
I put one line in that: println "hello world".
Without changing the "source sets" in build.gradle yet I now see one of those dreaded "red exclamation marks" next to the one line of the file. The message is:
Multiple markers at this line
- The type groovy.lang.GroovyObject cannot be resolved. It is indirectly referenced from required .class files
- The type groovy.lang.MetaClass cannot be resolved. It is indirectly referenced from required .class files
- implements groovy.lang.Script.run
There are surprisingly few reports (particularly recent ones) of this problem in SO or more generally when I search.
One suggests adding the Groovy Runtime Libraries to the build path configuration ... did that: not solved.
NB I have also tried repeatedly 1) rebuilding the project 2) refreshing Gradle 3) running the "build" task 4) closing Eclipse and starting up again.
NB2 I have not yet installed Groovy or Gradle in the general system: only for Eclipse. Could this be anything to do with it? Seems unlikely.
Seems like this was a "schoolboy error".
I just had to include this line in build.gradle (I haven't currently got access to my other machine so wasn't able to make the comparison).
apply plugin: 'groovy'
Will leave the question, unless there is massive objection, because it might help others who get puzzled...
For me problem was: I had put my XXXSpec.groovy file under src/test/java instead of src/test/groovy
Related
I have been happily using the mvn release:prepare command on my Macbook pro for some time and really like it. Unfortunately, due to circumstances, I need the projects to be maintained on a Windows 10 machine. After cloning a project (where release:prepare worked fine) and doing a release:prepare, I now get an error that the pom.xml cannot be found:
[ERROR] The goal you specified requires a project to execute but there is no POM in this directory (<XXXXX>). Please verify you invoked Maven from the correct directory. -> [Help 1]
This is correct because <XXXXX> is a different directory than where I execute the maven command. I have tried to forcibly set the location of the pom.xml file using the following line in the configuration of the release plugin:
<pomFileName>${project.basedir}\pom.xml<pomFileName>
This does not solve my issue. Am I the only one that has this problem on Windows 10?
I am using:
maven version: 3.6.3
release plugin version: 2.5.3
java version: 11.0.17
Weirdest part is that mvn release:clean works fine.
I am not sure if this is a release plugin issue because when running the following maven goal it has a similar problem. The tests fail because it cannot find file in the project folder (folder the command is executed in)
mvn clean verify
I was expecting the release:prepare goal to work the same on Windows 10 as it did on MacOS.
Execution failed for task ':app:iterateDeclaredDependencies'.
> Could not get unknown property 'scm' for configuration container of type org.gradle.api.internal.artifacts.configurations.DefaultConfigurationContainer.
I'm using the exact code snippet from Working with Dependencies
I don't know what scm is here but autocompletion seems to suggests that all is good, no?
Versions I'm using:
------------------------------------------------------------
Gradle 5.4.1
------------------------------------------------------------
Build time: 2019-04-26 08:14:42 UTC
Revision: 261d171646b36a6a28d5a19a69676cd098a4c19d
Kotlin: 1.3.21
Groovy: 2.5.4
Ant: Apache Ant(TM) version 1.9.13 compiled on July 10 2018
JVM: 1.8.0_191 (Oracle Corporation 25.191-b12)
OS: Mac OS X 10.14.6 x86_64
To query specific dependency sets, they must be declared first. scm doesn't exist, thus Gradle fails with an error message. Additional dependency sets can be added like this:
configurations {
scm
}
(Defining custom configurations)
Try with one of the defaults instead, for example implementation.
I'm not an IntelliJ IDEA user, so cannot tell exactly why autocompletion works in this case.
I'm trying to compile boost 1.66.0 on my Windows machine. I've got Visual Studio 2017 (Community) installed as my IDE and the 14.1 compiler definitely works. However, if I try to invoke this inside any of the VC2017 native command prompts
.\bootstrap
.\b2 variant=debug,release link=shared,static threading=single,multi address-model=64 toolset=msvc-14.1
I get plenty of the following errors:
'cl' is not recognized as an internal or external command, operable
program or batch file
If I change the toolset to msvc-14.0 everything works fine. I've also compiled boost 1.65.1 with msvc-14.1 sucessfully. However, there have been a number of Visual Studio updates since then.
Edit: I've tried compiling boost 1.65.1 again with the most recent compiler version (19.12.25834) and I get the same issue now. Calling "cl" manually inside the "x64 Native Tools Command Prompt for VS 2017" works fine though.
My solution was to:
Delete "C:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd"
Build again
My assumtion of reason: Boost makes a temporary "cmd" file which might be from an old build that did not support "msvc-14.1". The file is not rebuilt/deleted.
Background:
I had the same issue with one of my two development machines, both very similar (Windows 7) and updated with VC2017.3. The one working complained about the "Unknown version" (_MSC_VER=1911), but completed the building. The failing one had the "cl is not recognized" error. When looking at the point of failure it explicitly said that it was calling "C:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd".
I did a compare at both machines and found that the failing one did not include setting __VSCMD_PREINIT_VCToolsVersion=14.12.25827. There might have been other differences but this one was for sure.
I assumed that I was missing some SW packages or environment settings, but found it strange that the file was not deleted when doing a "b2.exe --toolset=msvc-14.1 --clean-all".
My solution was to delete the temporary cmd file - allowing it to be rebuilt.
After manually deleting "c:\Users\'username'\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd", the building worked fine (except for the 1.65.1 complains about the version _MSC_VER=1911).
Running a TeamCity build agent to run NUnit tests on Ubuntu 14.04 LTC with the latest build of mono appears to have some dependency issues that I cant for the life of me solve.
I have followed the following installation steps
Mono Installation Steps for 4.0.1
Team City Build Agent
When the TC Build Agent starts the NUnit step, it simply fails, and looking at the logs shows it executes
/usr/bin/mono-sgen /home/ubuntu/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe
which promptly returns with
Corlib not in sync with this runtime: expected corlib version 117, found 111.
Loaded from: /usr/lib/mono/4.0/mscorlib.dll
Download a newer corlib or a newer runtime at http://www.mono-project.com/download.
Is there any possible way to get this to work? I have tried removing all the pieces and re-installing again and even installing a older version of mono build but to no avail.
The TC connection appears to work and I can manually invoke and call mono on its own and even nunit-console however this .exe build provided by TC seems to have be stumped as linux non-expert.
Please save me from dependency hell!!
Edit: I ended up just solving my problem by installing nunit-console and enabling the XML Report processing build feature rather than play around with the corelib files and break something else.
This is a Mono bug, see https://bugzilla.xamarin.com/show_bug.cgi?id=34675.
The problem is that Mono moved to providing the 4.0 assemblies, including mscorlib.dll, only in form of reference assemblies. They contain only metadata and are intended for the compiler. Normally applications just use the newest version automatically.
The loader code in Mono however wasn't updated to bind forward an explicit runtime version of v4.0.20506 or v4.0.30128 which TeamCity is using in their .exe.config files to the latest version. The runtime instead tries to load mscorlib.dll from the 4.0 directory and bails as the version is too old (it's from the time the reference assemblies were generated).
As a workaround, you can edit <build agent
installdir>/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe.config (and other .exe.config files)
and remove the following lines:
<supportedRuntime version="v4.0.20506"/>
<supportedRuntime version="v4.0.30128"/>
This might stop working once TeamCity decides to update the plugin though.
Replacing the mscorlib version is only asking for trouble - i.e. TypeLoadException's and friends are waiting around the corner to get you.
What I did was replace the Teamcity build step with a manual invocation of the TC NunitLauncher, but forcing it to use Mono 4.5:
mono --runtime=4.5 /Applications/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe v4.0 MSIL NUnit-2.6.3 $(find **/bin/Release/*Tests.dll | paste -sd ";" -)
The invocation uses some shell trickery to find all assemblies I'm interested in using a wildcard, but other than that should be straightforward to understand.
It would be nice if Mono fixed their broken 4.0 runtime. Anyone already reported it on https://bugzilla.xamarin.com/ ?
This is how I worked around it : (note my mono is in /opt/mono)
$ cd /opt/mono/lib/mono
$ sudo mv 4.0 __4.0
$ sudo ln -s 4.5 4.0
i.e get rid of the 4.0 folder and symlink the 4.5 to be 4.0
This is something of a hack but it got me up and running until a proper fix surfaces!
Steve
I had this problem on my Raspberry Pi after compiling 4.0.2 but it was loading from /4.5/
This got me going:
sudo mv /usr/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5/_old_mscorlib.dll
sudo cp /opt/mono-4.0.2/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5
Where could I acquire a working copy of compiled JavaFX app bundled with JRE so I could execute this app on ARM linux?
or
How can I create my JavaFX app + JRE bundle that would work on ARM Linux
Best case scenario for me would be to be ableto create copy-paste enabled folder tree or single executable file..
I do understand that this question might be too vague, but I desperately need some help on this. I have spent more than 6 evenings + 2 nights searching how to get a compiled JavaFX application ( .jar file) to run on ARM linux on UDOO (RPi2-like) board.
I have been more of an .NET guy a long time, and now I had to make WPF-like rich UX app that would run on this specific hardware, and I chose JavaFX due to its likeliness to WPF. It does run fine on my desktop PCs but I absolutely can not get it to run on ARM linux.
I am trying to do this too. Did you get it working? My solution is to package the JAR using tools provided by IntelliJ or any other IDE, include the JRE in a folder within the app, then write a script that invokes the JAR from the included JRE like:
lib/jre/bin/java -jar runthis.jar
I also tried it for two days now but didn't get it to work.
I use maven in combination with the javafx-maven-plugin to build native installers of an application.
At first I got the error, that the javafx-ant.jar tools are missing:
[ERROR] Failed to execute goal build-jar(create-jfxjar) on project foo:
Execution create-jfxjar of goal build-jar failed: Plugin javafx-maven-plugin or
one of its dependencies could not be resolved: Could not find artifact
javafx-packager:javafx-packager:jar:1.8.0 at specified path
/opt/jdk1.8.0/jre/../lib/ant-javafx.jar
Then I found the ant-javafx.jar in a windows JDK but then another error was reported that linux is not supported with this one. Ok so I downloaded a linux JDK and used that ant-javafx.jar. Now it could build and create a *.deb file successfully!
However when I started the installer it failed with a message and when checking the log (/var/log/apt/term.log)
Log started: 2021-04-29 00:40:01
dpkg: Error creating archive
/home/pi/Foo/target/jfx/native/foo.deb (--unpack):
package architecture (amd64) does not match system (armhf)
Then I did research and found the following mailing list entry:
[...] the Java Packager isn’t shipped with any ARM builds that I’m aware of. Currently it is only for X86 Windows, Linux and Mac. [...]
This basically explains it: The packager doesn't work on ARM for now. Maybe we should write the guy to encurage him to add it...
=> So for now I work with the jar directly.