How can I tell sbt-assembly to keep its existing merge / deduplicate rules, except, when two .class files conflice, rename (and issue a warning so I know about it)?
Would this be identical to the shade strategy used in Maven?
The rename strategy literally just renames the file and it doesn't change the contents, so it won't work for .class files. The main use case for rename is for LICENSE files.
Updated in September 2015:
sbt-assembly 0.14.0 adds shading support.
sbt-assembly can shade classes from your projects or from the library dependencies. Backed by Jar Jar Links, bytecode transformation (via ASM) is used to change references to the renamed classes.
assemblyShadeRules in assembly := Seq(
ShadeRule.rename("org.apache.commons.io.**" -> "shadeio.#1").inAll
)
Related
I understand that you can create a separate yang file (Something like a textual Convention to store syntax values for MIBS)and import it into another yang file to make the data more organised and structured, but I can't seem to understand what the include statement does differently?
Does it "import" the entire file into the file that's including it - and if so would this be read before the file including it...?
Please help :)
YANG relies heavily on a concept known as "namespaces", which stems from XML naming conventions. Each namespace has a unique resource identifier and allows definitions (in different namespaces) to have same names at same definition levels while avoiding name clashes. When you define a YANG module, you are actually defining a namespace.
An import statement is used to access definitions from a foreign namespace (another module), while an include statement introduces a mechanism that allows a single namespace (single module) to be logically split into several files, conveniently named module and submodules. For includes, there is always exactly one module file, which includes all submodule files that belong to it. A submodule may only belong to a single module and may not be imported (directly). To an importing module, a module that includes submodules, looks like a single entity. Submodules may include eachother, but with YANG version 1.1, this has become unnecessary, since a submodule immediately gains access to all definitions in all submodules and the module they all belong to. In YANG version 1 you had to explicitly include a submodule to use definitions from it in another submodule, while never being able to access definitions in the module to which they belonged.
An import does not "inline" definitions into the importing module, while an include does exactly that. Importing a module gives you access to its top-level definitions (typedefs, groupings, idenitites, features and extensions) and allows you to use schema node identifiers that identify nodes in the imported module (for the purpose of augmentation and deviation, for example).
Definitions from a foreign namespace are always accessed via a prefix, which are part of an import statement's definition. Definitions that come from includes do not need to be prefixed when used, and if they are, are prefixed with the including module's (or submodule's) prefix.
YANG "compilers" usually process these files when they hit either an import or an include statement. They need to process them in order to be able to resolve definitions in body statements of the defining module. That is why these statements are required to appear in a module's header section.
There is an entire section in YANG specification dedicated to modules and submodules, where you can read more on the topic.
Is there a way to tell the sbt-onejar SBT plugin to produce a JAR in such way that the .class files of my project are in "expanded" form and not under lib/myproject.jar?
Alternatively, is it possible to tell sbt-onejar to produce a JAR that, when it's loaded, it actually unpacks/expands the nested JARs into a temporary folder and loads them from there, so that things like getResource(...) return paths to physical files as opposed to jar:file:... URLs?
Alternativel, I'd also happy with any vanilla OneJar solutions that help me produce a fat JAR wherein my own .class files would be directly under the fat JAR as opposed to under lib/myproject.jar.
I'm asking because Jetty does not seem to be able to load JSP files from inside of nested JAR files. There does seem to be a workaround by using a custom resource loader (see http://dev.eclipse.org/mhonarc/lists/jetty-users/msg01174.html for a report of the same problem and the workaround) but I don't seem to be able to get my servlets to actually use the overridden getResource method provided in the workaround.
After having read sbt-onejar's source code:
packageOptions in oneJar ++=
Seq(sbt.Package.ManifestAttributes(
new java.util.jar.Attributes.Name("One-Jar-Expand") -> "some-file.txt"))
However, I've realized using OneJar with Jetty is quite a problematic beast due to how Jetty loads JSP files—doesn't seem to work with nested JARs—so I'm looking into alternatives now.
EDIT: I've found https://github.com/xerial/sbt-pack and it seems to achieve the same effect as OneJar with the difference of being standard and thus free of problems, much faster, more customizable, and allows defining of convenient custom program entry points.
I have two managed assemblies that use a common batch of code. When referencing one to the other, the compiler complains about multiple redefinitions, as expected. Would it be possible to ignore the common symbols present in the referenced assembly during project compilation ? Or perhaps some other method/workaround to allow such a setup ?
As per above comment, fixed by changing the common code's access modifiers to 'private'.
When working with cmake, is it better to work with one large CMakeLists.txt in the root of the project, or as seems to be seen in some places, having one in each subdirectory too?
I would assume something along the lines of for large projects, having one in each directory is better.
If so, where should the threshold be?
I would certainly go for using multiple CMakeListst.txt files.
As a rule of thumb I think you should go for one CMakeLists.txt (and thus subdirectory) per target. So, each library or executable has its own CMakeLists.txt.
You can then create one "master" CMakeLists.txt that includes all the others using the add_subdirectory call. If you take care that you order these statements correctly, you can easily reference previously defined targets in the other CMakeLists.txt file.
If I have a package (foo.bar), is there some groovy sugar that makes it easy for me to enumerate all the classes in said package?
Groovy is built on top of Java so when it comes to class loading, any Groovy class is just a Java class. Java does not provide a way to do what you are looking for. You would think it would be a method on http://java.sun.com/javase/6/docs/api/java/lang/Package.html but there is not anything to list the classes.
There is a way you can do it if you really need though. Classes are just files on disk. Listing the files that end in .class would give you the list of Java classes. If you are looking for the contents of a Jar file (which is just a zip, see this for reading jars), you can open the jar and look at each class in the archive. Directory structure always corresponds to the package structure so it should not be hard to take a package you are looking for and list all .class files in that directory.