I have a Play project that I would like to deploy via RPM. I'm trying to use SBT to build the RPM, on CentOS, using the sbt-native-packager RPM plugin.
At the end I gt the rpm package.
But it stored in directory under %appname%/target/rpm
How can I use my own path for rpm buildroot tree?
Say, for example /home/build/buildroot
Sbt-native-packager version in use 0.8.0.
The simple (rpm config centric) answer is to configure %_topdir in ~/.rpmmacros before invoking rpmbuild. SBT may be adding additional complexities.
Related
ACE and TAO is used for our deployment and they will be required to be packaged as RPM from now on (for SUSE platform if it matters).
While I know there are RPM files available we have some specific "$ACE_ROOT/include/makeinclude/platform_macros.GNU" file that we use and we would like to have the RPM build out of the binaries resulted from our own build.
Can we create an RPM after following the steps from ACE-INSTALL.html, based on that build output?
See ACE_wrappers/rpmbuild for the spec file that is used for all RPMs on OpenSuSE Build service. Couldn't you extend that script with the options you need and contribute that back into the main github repo?
I am trying to install a NuGet tools package inside an Alpine Docker container.
In Windows I would do the following -
nuget install SomeToolPackage
Doing so would result in a new set of directories like -
tools\netcoreapp2.1\SomeTool.dll
tools\netcoreapp2.1\* many other files
Question
What is the equivalent in for Linux. I am aware that some people are using Mono to run the Windows nuget.exe file.
I can also use wget and unzip.
I hope there is a better way using the tools from Microsoft.
The path going forward is to use dotnet tools (see also dotnet core global tools overview and creating a global tool). However, it's not a 1:1 mapping with nuget.exe install, as the package must be authored as a tool, whereas nuget install allows you to "install" any package.
Help install the eisenvault-esign module.
I tried to install files
"eisenvault-esign/ev-esign-repo/target/ev-esign-repo-1.0-SNAPSHOT.amp"
in the "\amps" folder
and
"eisenvault-esign/ev-esign-share/target/ev-esign-share-1.0-SNAPSHOT.amp"
in the "\amps_share" folder
But when you start apply_amps.bat module is not installed.
Alfresco version 5.2
Below is the execution process.
When you run apply_amps.sh you need to pass in the -force flag because the module you are trying to install overwrites shipped libraries as indicated by your console screenshot.
You should also file an issue with the owner of that project to ask them to adjust their AMPs so that they can be installed without the force flag.
Because I use the Netlify CLI tools on travis, I need to have a node version above 8 but the R container I use only has 6.12 according to the error message. I saw that it is possible to specify the node version for java script projects and there is an answer for PHP projects here on StackOverflow, but I tried both and they did not work for my case. What is the proper way of installing a specific node version in an arbitrary travis container such that other applications can access it ? Or maybe even better, (how) can I make npm satisfy the minimal version dependency on node when installing the Netlify CLI tools? I have no prior experience with npm. You can find the version history of my .travis file here.
To install Netlify CLI, make sure you have Node.js version 8 or higher
Based on the docs for Netlify here
Quickest solution for Travis
Optionally, your repository can contain a .nvmrc file in the repository root to specify which single version of Node.js to run your tests against.
The quote from the docs say to add a .nvmrc file to your project at the root with the version
.nvmrc
8.14.0
Note: replace the version with the one compatible with your project that meets all requirements. Also, the .nvmrc file is only read when node_js key in your .travis.yml files does not specify a nodejs version.
Based on the solution provided by #talves, I figured out I can modify the before_script step to install a specific version of node, e.g. 8.14:
before_script:
- nvm install 8.14
- npm install -g netlify-cli
- Rscript -e 'blogdown::install_hugo()'
As nvm and npm were already installed. To install the latest stable release replace 8.14 with node above. That way, I don't need the .nvmrc file.
I'm interested in building an RPM package for sbt 0.12.3 that meets the Fedora packaging guidelines. In order to do this, I'll need to be able to build sbt itself against libraries that were built from source and installed via RPM packages.
Java packages in Fedora that use Ivy are able to resolve RPM-installed artifacts by disabling network resolvers and resolving all packages from /usr/share/java/[artifact].[ext] -- see here for an example.
I think I understand how to override default resolvers in sbt using a boot properties file, but this is where I run in to a problem: if I set the Ivy directory to /usr/share/java, sbt expects to be able to publish artifacts to this directory (not merely to look for existing artifacts there), which I don't want it to do (both in general and for this specific case of RPM building). If I specify file:///usr/share/java as a proxy location (following Mark's instructions below), sbt will fail (citing the absence of ivy.xml in that location).
I am able to find locally-installed dependencies by modifying project/p.sbt to point to explicit URLs (e.g. "org.jsoup" % "jsoup" % "1.7.1" from "file:///usr/share/java/jsoup.jar"), but this doesn't work for scala and the scala library (and is obviously not the right thing to do in general).
How can I build sbt against (and only against) locally-installed, RPM-managed system Scala and libraries?