I wrote a custom Gradle task to encapsulate a Java application, https://github.com/ndw/xmlcalabash1-gradle
It's a fairly simple extension of org.gradle.api.internal.ConventionTask cobbled together somewhat quickly. It's entirely possible that I'm just doing it wrong.
It's been working just fine for a while now. I've used it in several projects. However, for the particular build.gradle that I'm writing now, I need to make additional classes available to it.
After much frustration and complete failure to get additional jars into the classpath, I went back and updated my application class so that it would print out its classpath. That revealed that when this task runs, the classpath consists of only /usr/lib/gradle/4.4.1/lib/gradle-launcher-4.4.1.jar. I conclude that some alternate class loader must be in use because the task does successfully load the core application classes.
Can anyone tell me how to make more jars available to my task? None of my web search foo has lead me to an answer.
Oh, for the love of all things. I left 'classpath' out of the dependencies in the buildscript closure. #facepalm.
Related
So I have been struggling all afternoon with getting some Gradle build to work for a Kotlin multiplatform project that involves an ANTLR grammar. What I'm trying to do is to have a parser generated by ANTLR from a shared grammar for both a Kotlin (or Java if that doesn't work) and JavaScript target. Based on this I'd like to write some library around the parser that can be used from the JVM and JavaScript.
So I have set up a Kotlin multi-platform project because that seemed like a nice way of killing two birds with one stone (here is a repo https://github.com/derkork/project.txt). I created a source set commonAntlr where I placed the grammar file under commonAntlr/antlr/project_txt.g4. According to the documentation of the ANTLR plugin this is how stuff should be set up. I also apply the antlr plugin at the top (here is the build.gradle.kts - https://github.com/derkork/project.txt/blob/master/build.gradle.kts).
Now I run gradle build in the hopes that the ANTLR plugin will at least try to generate some nice Java code for me from the grammar using the default settings. Alas, it does not. The ANTLR plugin does not even get started, which is what I can tell from the output. The build later fails with some obscure JavaScript problem, but that looks unrelated and I'd like to skip over it for now.
Now my Gradle-foo isn't exactly strong (I have only used it in extremely simple projects, most of my experience is in Maven), and I have the distinct feeling I'm missing something here. However the documentation of the plugin just says
To use the ANTLR plugin, include the following in your build script:
plugins {
antlr
}
Which I did. Since I get zero output, I have a feeling that I need to do a bit more for this to work. I have read a lot of the Gradle documentation up and down to find out how plugins work in general and I found that they add tasks to the build and also add some dependencies so that tasks are invoked when you try to build certain things. However I don't really understand how plugins work together with source sets and how you can tell Gradle "would you please run the generateGrammarSource task for this source set" (or if it even works like this).
So if some of the Gradle gods could enlighten me on this, this would be much appreciated :)
I have met a similar issue: https://gitlab.com/pika-lab/tuprolog/2p-in-kotlin/tree/feature/parser
My solution -- which is still a work in progress -- consists in decomposing the problem.
I reasonable solution in my opinion is to create a Kotlin/JVM project (say parser-jvm) where to put the generated Java code + any JVM specific facility, and a Kotlin/JS project where to put the generated JS code + any JS specific facility (say parser-js). The next step is to create a Kotlin/MPP (say parser-common) project whose JVM implementation depends on parser-jvm and whose JS implementation depends on parser-js.
My approach is actually working for JVM while I'm experiencing some issues for JS, which are mostly caused by this issue.
The main drawback of this approach is that some Gradle coding is required to setup ANTLR with Kotlin/JS. I already faced this problem in my build.gradle and I'm quite satisfied with the result and the overall architecture of the project. However, I believe that my proposal is far less troublesome than configuring a Kotlin/MPP project to work with ANTLR.
I have a project which uses kapt for annotation processing and code generation (based on the annotations). It works in the main sources, but not in the test sources.
Some sources (e.g. how to use kapt in androidTest scope) suggest to run gradle kaptTest, but this does not work either. It reports the task as "Up to date", even directly after a clean. Maybe this suggestion is unique to android.
I downloaded the example project from https://github.com/JetBrains/kotlin-examples/tree/master/gradle/kotlin-code-generation, added an annotation usage in the test sources and I got the same behaviour there. It works well for the main sources and it does not work for the test sources.
The only odd thing in the output is:
> Task :example:compileKotlin
Using kotlin incremental compilation
w: [kapt] Sources output directory is not specified, skipping annotation processing
but as you can see, this is not the test sources, but the main sources, and the annotation processor is applied on those.
I added a printout in the annotation processor. It does show up for compileKotlin, but not for compileTestKotlin.
So, what is the magic trick to make kapt work on test sources?
PS: I guess someone is going to ask for my build.gradle. It is identical to the one from the example I linked, so if you can make it work for the example, I can integrate into my buildfile.
PPS: Only similar question I found is Kotlin's kapt plugin for gradle does not work for custom source set (JMH), and they suggest to issue a bug report. So maybe it is a bug in the kapt-gradle-plugin?
Some sources (e.g. how to use kapt in androidTest scope) suggest to run gradle kaptTest, but this does not work either.
You misunderstood the suggestion. It says kaptTest should be used in place of kapt in the dependencies block, as described here, not that you should run Gradle differently. OTOH, the documentation also specifically says
Note that kaptAndroidTest and kaptTest extends kapt, so you can just provide the kapt dependency and it will be available both for production sources and tests.
So there indeed seems to be a bug there.
I've linked this question in https://youtrack.jetbrains.com/issue/KT-21891. I didn't want to file a separate bug because I don't know which Gradle/Kotlin/Kotlin Gradle plugin/etc. you had.
As suggested above, kaptTest should be added in gradle for the annotations in test folder to be processed by kapt.
for example for dagger hilt, add this to your app gradle :
kaptTest("com.google.dagger:hilt-android-compiler:$hiltVersion")
or for moshi, when you use annotations like #JsonClass(generateAdapter = true) in a file in test folder, you should add this to gradle dependencies so that kapt processes the annotation and generate the class :
kaptTest("com.squareup.moshi:moshi-kotlin-codegen:$moshiVersion")
I'm setting up a (java) maven project that depends on a library (Jettison, among others) that is in the Maven repo. Jettison, in turn, depends on stax. I need to run a tool (Jar Jar Links) on stax (to change the namespace). How do I alter the rules for a transitive dependency in a maven project? My transitive dependencies are being included in my target folder using the copy-dependencies goal (I assume this is how things are usually done). I assume that this is the point where the plugin would be run on the transitively-generated artifact.
Extra question: I don't need this at this point but how would I go about altering the source in the transitive dependency? I can get the jar of the source with mvn dependency:sources but, from there, I'm not sure what the right approach is.
Victory!
Seems at least two people are even more clueless about Maven than me so let me explain what I'm doing before I report the fix at the bottom of this post (spoiler alert: it looks to be a bug in JarJar).
Android uses Java but its missing a lot of the java core (specifically, javax classes). The Android DEX compiler (which converts .jars to Android .dex files) won't even allow you to compile things in the java.* or javax.* namespace because it'll (usually) break stuff. However, in some (many) cases, there are routines that you might want to include -- specifically because they are used by existing libraries. The most legendary is StAX, which is why Google posted an example of how to include it here in the Dalvik repo's wiki. The example uses JarJar... with ant. Transitive dependencies are not really an issue when you aren't using a repo so they are not addressed in the wiki.
I was able to get JarJar to run on my source with Maven but without changing the namespaces in the dependencies (and transitive dependencies), that's worthless. Hence my question.
I thought that the copy-dependencies plugin might be useful for... copying the dependencies and running a transforming plugin in the process. Copying dependencies is mentioned as a step in the official "Maven in 5 minutes" doc so it seemed like a good start but maybe the the people who wrote the official docs don't know how to use it :-) . Either way, it it didn't help -- there is no simple way I could see to transform the jars as it copies.
Using the verbose spew from Maven, I was able to see that Jar Jar was in fact processing my jars properly... and then throwing out the result. It would have packaged the converted classes from the transitive dependencies in my artifact with the rest of my code but, instead, it "Excluded" them. Jar Jar parameters are basically undocumented and most of the tags aren't even listed in the docs but all of the examples I could find use a section with wild-cards that tell it what classes to hold onto. At least I thought (think?) that's what the section is for. Instead, it seems to randomly throw out stuff. Basically, the section is busted. For example, I had:
<keep>
<pattern>com.example.**</pattern>
</keep>
...thinking that this would keep classes that began with com.example. Wrong. It keeps whatever the hell it wants. I tried a million things in that spot until one worked:
<keep>
<pattern>*.**</pattern>
</keep>
This only keeps the classes I wanted -- the classes it updated and the originals of the ones that it didnt touch. Note that ** doesn't even work. This is version 1.8 of the JarJar plugin (the version most poms Ive found use).
Back to work.
Trying to build Spring-based application one needs to figure out all necessary dependencies the application will have.
For example, I was using HibernateTemplate, and each time I run the application the ClassNotFound exception comes out. So I “google” for jars that contains this particular class, after search mvnrepository to find appropriate artifact. Always confuse about which version to use.
And it’s happened again and again, and only after few hours and few dozens of dependencies added the application become runnable.
But even after that, I tried to use my app. on different computer with slightly different parameters, and slf4j class not found error appeared, even after testing extensively on the developer machine, still some dependencies missing.
Now it works fine, but I want to distribute my application, and not sure if on another system there will no dependency missing.
So, what is the best practice to determine all necessary dependencies not only at design time but in runtime too? Is there any tool for that?
How one can manage versions confusion, when there are dozens of dependencies each with its own version?
They both resolve dependencies, so you keep a dependency file and it does all the heavy lifting of making sure everything is included in your builds. Use the full spring dependency list. I had problems with SLF4J too.
http://mvnrepository.com/artifact/org.springframework/spring-full/1.2.8
OSGI Testing frameworks - some observations.
I am in the middle of writing a system that makes use of OSGI. However all of the popular testing frameworks (Spring-OSGI, PaxExam) require a lot of artefacts for even the simplest test.
Wishlist / Goals
Ideally i would like a single Test that uses TinyBundle to assemble bundles and gives them to the framework. The framework will then do the heavy lifting of starting the container, deploying, running each test, updating the ui to show results etc.
On the surface it would appear that PAX-EXAM would satisfy this but it has additional requirements, which I have not been able to solve, within Eclipse. My problems are:
Each bundle requires a separate project.
Each project gets a manifest.mf in the $project/meta-inf/.
Ideally i would like to bundle all my manifests and "internal" classes in separate sub packages of the test rather than having them scattered about in their respective projects.
I have found packaging everything into the one project just does not work when the tests
execute even if the bundles provisioned are identical in content. However if i split everything into separate projects stuff just works.
Maven
I wish to avoid maven as this implies that a more complex system that would end up requiring building, deploying into the repo which in the end even when automated just slows things down even more. This would conflict with my use of Infinitest which automagically detects changed classes and just executes the right tests.
Eclipse Project Plugin launch configurations.
This approach requires one to pick the bundles to deploy prior to executing the junit test. This of course only works if one has separate projects with a one to one mapping per bundle. Again this goes against my attempts to consolidate all test dependeny bundles under one project.
How, Can it be done ???
How can i achieve this ?
Is this practically possible ?
Whats the simplest alternative ?
One alternative, which also leverages Pax Exam, is what we did in an OSGi testing framework (that tests OSGi framework implementations). Rather than duplicating the whole explanation of how it works, you can find that here:
http://opensource.luminis.net/wiki/display/OSGITEST/OSGi+testing+framework
It does not use Maven, and writing new tests is explained here:
http://opensource.luminis.net/wiki/display/OSGITEST/Writing+a+framework+test
Maybe some of the solutions can inspire you. All in all, there are many test frameworks out there for OSGi (just like there are for non-OSGi) but so far there has one been any one that "makes the rest obsolete".