Resolve optional non-jar artifacts with sbt - sbt

My company uses .zip sources for some of its libraries. Is there any way for me to tell sbt to search for .zip extension as well as .jar?
I've tried specifying the artifact dependency explicitly through an artifacts(Artifact(...)) call, but that makes the sources required, as opposed to optional the way jar ones are.

Related

Can i place native dependencies in a subfolder

When i publish a dotnet core project, it generated a single folder with hundreds of framework and native runtime files in it.
I understand that these files are required to make everything work, but can i move them into a subfolder and still get my app to run?
For example
MYAppFolder\
MyApp.exe
MyApp.exe.config
native\
hostfxr.dll
netstandard.dll
...
Is there some sort of probing path configuration that can do this?
As far as I can see you have a Standalone (SCD) app.
For that type of deployment hostfxr.dll should always exist in the app directory by convention.
As to other deps, you are able to move them to any locations, however you'll need to edit [AppName].deps.json for every build and also specify Additional probing paths. Besides, you are free to remove all the redundant dependencies (from deps.json and the file itself) if you are sure that you don't use them.
Check this demo where I've put all the dependencies of a Standalone app that could be moved to other location to a lib subdirectory.
please, note the following:
Additional probing path is set in HelloWorld.runtimeconfig.json but you can also use --additionalprobingpath [path] argument or Environment varibable
I've removed relative paths in deps.json file because otherwise I would have put the files to those relative paths sub directories - Additional probing path is considered to be a NuGet package cache thus have a package layout inside.
Also, consider having a Portable (FDD) type. You'll have a much less footprint and more flexibility arranging the files.

Leiningen: how to exclude dependencies when uberjaring?

When using leiningen to build Clojure applications, how can certain dependencies be excluded from being included in the JAR file when using lein uberjar?
Use the provided entry for the leiningen profile.
:profiles {:dev {:dependencies [[ring-mock "0.1.5"]
[prismatic/dommy "0.1.3"]
[org.bouncycastle/bcprov-jdk15on "1.50"]]}
:provided {:dependencies [[org.bouncycastle/bcprov-jdk15on "1.50"]]}}
One common use case is bouncycastle that needs to be excluded from the signed JAR and provided externally using its own jar file in runtime.
Similar to what Guillermo suggested modify your project's :profiles to include something along the lines of:
:provided {:dependencies [[org.bouncycastle/bcprov-jdk15on "1.50"]
[org.bouncycastle/bcpg-jdk15on "1.50"]]}
(The specific versions may vary.)
Trouble is that if you use a Clojure wrapper library (such as clj-pgp or thi.ng/crypto), it forces inclusion of the jar in the uberjar, breaking the process.
My solution was to fork the library and push it to clojars after modifying its project.clj to uses provided dependencies.
More details here: http://side-effects-bang.blogspot.com/2015/02/deploying-uberjars-that-use-bouncy.html
In the project.clj under :dependencies you can add exclusions for specific jars like this:
[test/test-jar "1.0" :exclusions [sample-exclusion/test-exclusions]]

How to unpack dependency jars into the classpath in target?

I am using sbt-osgi to repackage some library dependencies into OSGi packages, and that works well, until I started using scalajs as well. The library dependencies are defined as normal projects something like this:
lazy val bonecp = OsgiProject("com.jolbox.bonecp", buddyPolicy = Some("global")) settings
(libraryDependencies += "com.jolbox" % "bonecp" % "0.8.0-rc1")
The OsgiProject function has default OSGi settings plus some implicits for determining what path the project has. When the bundle task is run on these projects, a new jar with OSGi stuff is created based on the OSGiProject settings. This project just rebundles the bonecp library as an OSGi jar and has no sources. The problem here is that since there's no source, theres no files in target/scala-2.11. This causes sbt-osgi to spit out a ton of ignorable errors, but scalajs is not as forgiving and refuses to do anything with these projects. Is there any good way to unpack the downloaded libraryDependency jars into target/scala-<scalaVersion>?

Java compile error. servlet-api.jar

I created simple Java Servlet: WelcomeServlet.java.
Than, I tried compile this file via:
javac WelcomeServlet.java
In result I see compile error:
package javax.servlet doesn't exit
I try find solution for this error with Google. And I find first part of answer: java compiler doesnt see servlet-api.jar file.
I know, that Apache Tomcat in it lib folder contains servlet-api.jar file.
So, I have this file, but where I must copy this file??
I try different folders:
echo %JAVA_HOME%
C:\Program Files\Java\jdk1.6.0_26
%PATH% contains this line: C:\Program Files\Java\jdk1.6.0_26\bin
So, I copy in:
%JAVA_HOME%\bin
%JAVA_HOME%\lib
%JAVA_HOME%\jre\lib
And in result same error.
And only after I copy servlet-api.jar in directory:
%JAVA_HOME%\jre\lib\ext
compilation complite sucessful.
My question: Why? Why I must copy in folder %JAVA_HOME%\jre\lib\ext ??
Where This moment describe in documentation?
And other question we have some official docs or specifications that describe folder structure for jdk folder??
You'll need to specify the directory or directories you want the compiler to search by using the -classpath command line option when running javac. The reason the compiler found your .jar in %JAVA_HOME%\jre\lib\ext is because it searches the extension directories by default.
This is for Java 1.5, but I believe it is more or less still correct:
http://docs.oracle.com/javase/1.5.0/docs/tooldocs/findingclasses.html
The link Shaun provides is a more complete answer. But in short, using the classpath is the best way to introduce 3rd party or external (to the JDK/JRE) libraries. The classpath is a concept much like the %PATH% or the $PATH variables, but specifies locations for java to use for lookup rather than the shell to use for lookup of executables.
The classpath provides the java compiler or java virtual machine a list of items to use when searching for resources. This "path" may include directories or files. It will typically include jar files and sometimes locations of configuration files. Many Java based lookup schemes for files configuration or otherwise use some variant of what is accomplished by [Class#getResourceAsStream()][1]'s use of walking the Classpath.
I have rarely seen an incident where putting a jar file in the lib/ext location was preferred to utilizing the Classpath.
The classpath is typically an environment variable (%CLASSPATH% or $CLASSPATH) or specified on the command line when running java or javac (e.g. -cp or -classpath see the help from the executable you are running).
Build tools such as Ant and Maven will also provide abstractions to defining the list of jars to be utilized by your applications and are highly recommended to be used for any length of repetitive change code, build, test, run cycles.

In the Flex SDK, what are the "extra" .swc files in the libs directory that don't have matching signed framework RSLs?

Taking the specific example of SDK 4.5.0.20967, the SDK includes the following signed framework RSLs (.swz files) in "<sdk_path>\frameworks\rsls":
advancedgrids_4.5.0.20967.swz
charts_4.5.0.20967.swz
framework_4.5.0.20967.swz
mx_4.5.0.20967.swz --------> matching .swc is in libs\mx\mx.swc
osmf_1.0.0.16316.swz
rpc_4.5.0.20967.swz
sparkskins_4.5.0.20967.swz
spark_4.5.0.20967.swz
spark_dmv_4.5.0.20967.swz
textLayout_2.0.0.232.swz
The .swc files in the matching libs directory "<sdk_path>\frameworks\libs" are:
advancedgrids.swc
authoringsupport.swc ---> no .swz match
charts.swc
core.swc ---------------> no .swz match
flash-integration.swc --> no .swz match
framework.swc
osmf.swc
rpc.swc
spark.swc
sparkskins.swc
spark_dmv.swc
textLayout.swc
So 9 of 10 .swz files match the ..\libs\*.swc exactly, with the one .swz -> .swc mismatch being mx.swc which is one subdir below.
What I'm mainly wondering about is the seemingly extra .swc files:
authoringsupport.swc
core.swc
flash-integration.swc
What are they, and are they needed in a basic flex project? Documentation on them is sparse/non-existent.
I expect that the question may be a bit misguided and the existence of those three .swc files in the root of the frameworks\libs directory is somewhat irrelevant. However, the reason I was initially looking at this is that the IDE I'm experimenting with (Amethyst) seems to, at least, be including all .swc files it finds in the frameworks\libs directory into the project and I want to determine what I can manually remove.
These are default Adobe packages that enable things like bindings.
Best bet for figuring out what is required in your project because it's being implemented is to remove one at a time until your project fails to compile, and then restore them.

Resources