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.
Related
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
I have a distant linux system with a Tomcat containing Jenkins and the Sonar server (v 3.7.4). I am also using the Sonar Runner (v 2.1), but can I really use it in a linux environnement ? I mean, the bin repository only contains a .bat file, no .sh.
So if in Jenkins I set the SONAR_RUNNER_HOME to the path of my sonar runner install repository on linux, is it gonna work ? Because obviously if I want to run the .bat file myself to do test it (after the creation of sonar-project.properties file), well, I can't.
I didn't find anything about that on Google, as if there was no problem about it.
You can use sonar-runner which is shell script (it's marked as a Unix executable).
However, please note that Sonar 3.7.4 is really old (more than 3 years old). So I highly suggest to upgrade to latest LTS (5.6.6) and you will benefit also of the Jenkins plugin (https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Jenkins)
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
I'm attempting to build Apache Spark 1.1.0 on Windows 8.
I've installed all prerequisites (except Hadoop) and ran sbt/sbt assembly while in the root directory. After downloading many files, I'm getting an error after the line:
Set current project to root <in build file:C:/.../spark-0.9.0-incubating/>". The error is:
[error] Not a valid command: /
[error] /sbt
[error] ^
How to build Spark on Windows?
NOTE Please see my comment about the differences in versions.
The error Not a valid command: / comes from sbt that got executed and attempted to execute a command / (as the first character in /sbt string). It can only mean that you've got sbt shell script available in PATH (possibly installed separately outside the current working directory) or in the current working directory.
Just execute sbt assembly and it should build Spark fine.
According to the main page of Spark:
If you’d like to build Spark from scratch, visit building Spark with Maven.
that clearly states that the official build tool for Spark is now Maven (unfortunately).
You should be able to build a Spark package with the following command:
mvn -Pyarn -Phadoop-2.4 -Dhadoop.version=2.4.0 -DskipTests clean package
It worked fine for me.
I am trying to install CruiseControl.Net v1.8 on OS X Lion. I have the latest release of mono installed (2.10.9). I run:
sh build-all.sh
The build starts but immediately fails with the following error:
BUILD FAILED
../ccnet.build(47,3):
Target framework could not be changed. mono-4.0 is not a valid framework identifier. Valid values are: mono-2.0, moonlight-2.0, mono-1.0, mono-3.5.
Total time: 0.1 seconds.
I have not previously installed NAnt or CruiseControl.Net on this machine. I heard online that supposedly the newest version of NAnt does not have this problem, so I downloaded the latest version and replaced everything in CruiseControl.Net's Tools/NAnt folder with the contents of the newly downloaded NAnt's bin folder. After I did that and ran the build again I received the following error:
Williams-MacBook:CruiseControl.NET-1.8.0.0.source williamkeen [(no branch)] $ sh build.sh
Buildfile: file:///Users/williamkeen/Downloads/CruiseControl.NET-1.8.0.0.source/ccnet.build
Target framework: Mono 2.0 Profile
Target(s) specified:
[property] Target framework changed to "Mono 4.0 Profile".
BUILD FAILED
Target '' does not exist in this project.
Total time: 0.2 seconds.
Looking online some more I found that this was supposedly a guaranteed fix with CC.Net 1.6. Any help would be appreciated. I'm at the end of the road here, I have no idea what to try next.