How do I tell Heroku to use a specific version of Clojure?
The sparse (and mostly out-dated) Heroku Clojure documentation only mentions:
Heroku supports apps on any production release of Clojure, running on a supported JDK version.
But not how to set the version.
The uberjar build artifact will include the clojure version specified in your project.clj. So just make sure this compatible with the JDK version.
Related
So, https://sling.apache.org/documentation/bundles/configuration-installer-factory.html tells us that the currently recommended way to configure OSGi components is to use .cfg.json files. However, it notes that those are only supported “[…] since Installer Configuration Factory 1.2.0”.
So now I’d like to know:
How do I figure out which version of “Installer Configuration Factory” my AEM uses?
Which version of AEM comes preinstalled with Installer Configuration Factory ≥ 1.2.0?
If I’m on an older version of AEM, how do I upgrade Installer Configuration Factory?
I couldn’t find definite answers on any of these. But Adobe does sometimes also recommend using .cfg.json config files but only in articles about AaaCS. Is this only supported on AaaCS?
Sorry for my snarky tone but the lack of reliable, concise documentation is infuriating…
How do I figure out which version of “Installer Configuration Factory” my AEM uses?
goto /system/console/bundles
search for Apache Sling Installer Configuration Admin Support
This gives you the bundle you are looking for
The number as marked in screenshot is the version used by your AEM.
Which version of AEM comes preinstalled with Installer Configuration Factory ≥ 1.2.0?
I am on AEM 6.5.6 and the screenshot above is from the same instance. It exports out 1.1.2. The only version above this is 6.5.7, not sure if it has been upgraded to 1.2.0 as you need
If I’m on an older version of AEM, how do I upgrade Installer Configuration Factory?
You can build the bundle or download the already available one and install. However if there is any hard dependency on the existing version, your instance may corrupt. In order to avoid that, you may need to evaluate what all bundles are dependent on the existing version of configuration bundle and see if you can upgrade them all.
Short cut is to create a vanilla instance and deploy the configuration bundle exporting 1.2.0 version of configuration and test if instance comes up and number of active bundles is same and the ones before you upgraded configurations bundle.
What are the difference between net.wasdev.wlp.maven.plugins and io.openliberty.tools liberty-maven-plugin and which one should I use ?
New, preferred (3.x) version
io.openliberty.tools:liberty-maven-plugin
The io.openliberty.tools one is the newer, better version of the liberty-maven-plugin, and the one you'll likely want to use for new development.
Older (2.x) version
net.wasdev.wlp.maven.plugins:liberty-maven-plugin
The older net.wasdev.wlp.maven.plugins plugin is what evolved into the newer io.openliberty.tools plugin.
Along with the move from version 2.x to version 3.x of the liberty-maven-plugin, the groupId was also changed from net.wasdev.wlp.maven.plugins (versions 1.x-2.x) to io.openliberty.tools (version 3.x and beyond).
Why use the newer plugin?
Both versions of the plugins can be used to work with (install, deploy to, etc.) either Open Liberty or WebSphere Liberty servers. (so that is not a concern in choosing one vs. the other).
The newer V3 plugin provides the helpful new "dev mode" support. Plus you'll find a lot more recent material using this version such as the Open Liberty guides.
It also enhances and streamlines some of the other goals and configuration (besides "dev mode"). There's a summary of the 3.x enhancements here.
So at this point the only reason to use the 2.x plugin from net.wasdev.wlp.maven.plugins would be to continue with a project already using this version of the plugin (unless or until you're ready to migrate).
My builds broke when I moved to Gradle 5 becasue Gradle v5.2 bundles with Groovy v2.5.4. These projects use the dynamic support build for Groovy.
Invoke dynamic support
groovy-all-2.5.4-indy.jar
This file is not being resolved for either JCenter or MavenCentral. However I did find a copy here:
Sonatyoe repo: https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.4/
groovy-2.5.4-indy.jar
but no groovy-all-2.5.4-indy.jar
I am not sure what can be done for Gradle to 'resolve' this file and actually find it.
Can someone tell me were I should be getting this JAR file from?
I'm using coordinates: "org.codehaus.groovy:groovy-all:2.5.4:indy"
Is that still the correct expression?
Is this a bug or am I just looking in the wrong places (see #1)?
Im ny build.gradle I was using jcenter() and tried changing that to mavenCentral().
Neither option came up with the JAR in question.
A final wrinkle is that we run an instance of Nexus. Is there some way to force Nexus to go outside and look-for this JAR?
This is not entirely conclusive, but it seems that the -indy jar was there in groovy versions prior to 2.5.0 because those versions supported java versions prior to 1.7.
The indy jar was there so that you could optionally enable support for the invokedynamic instruction introduced in java 1.7 while still supporting java versions prior to 1.7 which did not include invokedynamic (groovy docs for indy).
It seems that groovy 2.5 bumped the minimum jdk requirement to, quote:
JDK requirements changes
Groovy 2.5 requires JDK8+ to build and JDK7 is the minimum version of the JRE that we support.
(from http://groovy-lang.org/releasenotes/groovy-2.5.html)
which would make this whole duality of supporting both invokedynamic and without unnecessary.
So my guess would be that they just dumped the indy jar and always include the invokedynamic instruction in the normal groovy jar file set as the required jdk versions will always include it.
Maven by default uses these versions of plugins such as clean, compile, jar etc. if I don't override them in my pom.xml.
Should I be using more recent version of these plugins? For example, the current version of maven-compiler-plugin is 3.6.1 while the default is 2.5.1. Or, are the default versions reasonable enough that anyone not consciously depending on newer features need worry?
The maven way is "convention over configuration", so if you're wondering about not using the default parameters when running a maven build, you should have a specific use case that is not covered by the default version.
Here for example, (according to here) the install plugin is still at version 2.5.2, so that would point to me that using 2.5.1 is not such a bad choice by default.
I think the biggest difference comparing version (I might be wrong) is the upgrading of compatible version as for example this pseudo release note of the maven compiler.
I'm at my wit's end trying to get Java3D working with Maven. The latest version in the Maven core repository is 1.3.1, but there don't seem to be any 64-bit dll files (without installers) that will work with such an early version! It seems that the 1.5.2 dll I donwloaded is incompatible (unsurprisingly).
Does anyone know of a repository that has at least version 1.4.0?
Otherwise, looks like I'm going to have to learn JOGL instead and change all my code.
Rather make a request for enhancement. Maybe we could publish Maven on Maven Central or at least in our development repository. Please check whether you're using Java 3D 1.6, look at that if you don't know how to install it.