I've created a new project by checking the "include kotlin" box in Android Studio 3 and out of the box I get an error while compiling
"Failed to resolve: org.jetbrains.kotlin:kotlin-stdlib-jre7..."
I have made sure all plugins are up to date and that the Android SDK is properly installed.
How can I solve for this error?
kotlin-stdlib-jre[7/8] was deprecated a while ago, and has since been removed. The deprecation note was kept until 1.2.71, which was the last version to release those artifacts. The official deprecation notice can be found here. Using any of the deprecated versions (before it was removed) should also produce a warning in (at least) Android Studio and IntelliJ.
Use kotlin-stdlib-jdk7 instead. It's the same dependency as kotlin-stdlib-jre7 (except newer), but it was re-named to kotlin-stdlib-jdk. kotlin-stdlib-jre is now no longer maintained as a separate dependency.
Both IntelliJ and Android Studio currently generate new projects using kotlin-stdlib-jre7; this likely is a bug. They have probably not updated the project generators. Therefore, you have to manually replace the dependencies with working ones until they fix this. This is dependent on the Kotlin plugin. Update it if you haven't. I haven't checked whether it's been patched or not - if it has, that only fixes the creation of new projects. For updating from older versions, the rest of the answer still applies
You naturally have to do this if you're on 1.2.71 or lower, and you're upgrading to 1.3.0 or higher.
These are the new valid dependencies as of Kotlin 1.3.0:
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version"
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
Where $kotlinVersion is either a variable containing the version, or a hard-coded version (i.e. 1.3.0)
Alternatively, you can use the "plain" stdlib (kotlin-stdlib) instead of the JDK-specific versions. But you have to change your dependency either way, so I recommend you go with kotlin-stdlib-jdk7, or if you plan on using Java 8, kotlin-stdlib-jdk8
The newest versions of the dependencies can also be found here. jdk7, jdk8, and the version-unspecific stdlib all follow the same versions (as per this edit - this could change in the future, but there'll likely be notices before that change happens), so whether you check jdk8, jdk7 or the regular one, all the versions should be universally available across the stdlib artifacts.
Note for other build systems
The same actual solution applies to other build systems as well, but the code is different. As there are a lot of build systems, I'm not going to include all of them, but the point is changing the artifact from kotlin-stdlib-jre[num] to kotlin-stdlib-jdk[num] (without brackets of course). Or, as mentioned earlier, kotlin-stdlib.
Independently of the build system, this bases itself on access to Maven Central and similar repositories. If your build system doesn't support this, and/or breaks with Maven-style conventions and repositories, you'll have to find what works for your build system.
TL;DR:
Use org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version or org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version (depending on which version you originally used) instead.
Remove this line from the build.gradle:
implementation"org.jetbrains.kotlin:kotlin-stdlib-jre7:$kotlin_version"
Add this line in the build.gradle:
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version"
Update the version build.gradle in project level:
kotlin version='1.3.0'
Related
Pentaho Data Integration 8.0.x is using Janino 2.5.16, released in 2010 for compiling the User Defined Java Class step. There is a JIRA in pentaho for updating this to use a newer Janino version which would bring new java 8 related features in pentaho v8.2.0 GA. But there is no info on when will this be released.
Is there any other way I can use a newer janino version (janino-3.0.8.jar) with exiting pentaho for UDJC? I tried to copy updated jar in the lib and also added commons-compiler-3.0.8.jar to fulfill dependency. Now when I open Spoon, I get the following error:
Please advise on how this can be achieved. I understand that just replacing the jar may not be enough but just want if something else can be done.
This is not easy. Even now, since you got ClassNotFound, public api of janino is changed. Some classes are removed some are changed. What is actual needs to update it?
If you need really complicated business logic, then create custom plugin. Documentation and tutorials are available and you can look into sources of current builtin plugins (sources are available on github).
What important new version of janino has, that old doesn't (beside java8 support)? Checkout kettle engine, look into sources of UserDefinedClass step, change code to support new janino version, test and make own build of pdi kettle, and try to send push request to maintainers of repository.
Any of this quite complicated, This plugin is builtin into engine, and you have to make own build. Own build means, you have to support it by yourself. This is non trivial, project is huge and now even bigger and continue evolving, I spent several days to make my first custom build (version of 4, was in ivy) just for purpose to know better and debug complicated cases, and it used never in production.
Maintainers of repository must have good reason to include your changes into stream, it must be well tested and it is long procedure and most probably doesn't worth it. A lots of changed since 2010, I probable have seen in release notes, new version of java already have abilities to compile at runtime.
My advice is to make you own plugin.
In CMakeLists.txt scripts, it is customary to have a:
cmake_minimum_required(VERSION x.y)
for the appropriate x.y version number. But - how can you tell what that minimum version is? I don't work with older versions; and as my distribution gets updated, so does CMake, so I may have even introduced commands requiring newer versions over time and I just don't know it.
I could theoretically require the versions I've tested this CMakeLists.txt with - but they're pretty new, and I don't want to restrict users of my code to just that.
There is no automatic way to do this. Here are some approaches I've used:
If you have used CMake for a while, you may roughly remember what features are newer and older. Select some of the features you use which you think are newer, and read the documentation to discover what version supports them.
If you can install just one or two old versions, it may be enough. CMake 2.8.x is very popular, so installing that and testing to see if it works (perhaps fixing it so it does) would be a nice service to some users.
Don't worry about it. Set the minimum to 2.8.10 and then accept patches or bug reports if users have specific issues. It's not likely that setting this number too low will cause any serious harm--typically it will just result in a different error message than "The CMake version is too old."
tl;dr: Try building with different CMake versions.
Download the CMake binary from https://cmake.org/files/ according to the claimed minimal required version. You can unpack them in some directory and use this CMake to ensure it is still the minimal required version. You can have as many versions as you wish in parallel. Don't forget to delete the build directory.
A problem you did not mention, but is also important: Check your code with newer version. New policies can lead to dozens of warnings, many projects try avoiding warnings in releases. So it might be good to have the latest version with the same procedure.
My project depends on library A in version n.
It also depends on library B, which in turn depends on A in a version n-1.
When running gradle dependencies the tree shows my project and B both depending on A in version n.
However, when I run gradle idea I get a workspace with both version n and n-1 reported.
Can I do anything to circumvent it and have get a idea workspace that conforms to gradle's dependeny resolution without forcing a version or changing the version I depend on?
I have already taken this to the Gradle list, but to no avail.
Update: I've uploaded a sample configuration, so you can experiment with it yourself. Note how Guava (A) appears in both version 10.0 and 11.0, thanks to both me and Reflections (B) depending on it.
From the example, I have learned that this only happens when the dependencies on A and B are spread across submodules.
Note: I know that Reflections 0.96 won't work with Guava 11.0. It just was the first thing that came to mind.
Just to be able to close this, here's what Peter Niederwieser wrote:
[This] is the expected behavior, not just for the IDEA plugin but for Gradle in general. This is because conflict resolution is currently done per configuration, not per build. When you execute gradle dependencies in Module1 and Module2, you'll get the same results as for the IDEA modules.
If both modules use Guava directly, you should specify direct dependencies, which solves the problem. Often this is done by factoring out the dependency declarations into a parent build script and referencing them by name from child scripts. (This is somewhat similar to Maven's dependencyManagement section.) Forcing a version for all configurations is another solution. I expect that future versions of Gradle will support build-wide conflict resolution.
Thanks for creating a sample project. This makes it so much easier to reproduce a problem. By the way, the best place to ask questions is http://forums.gradle.org.
In a pom.xml, when specifying a dependency version, what is the difference between LATEST and [0,) ?
In my opinion they should be equivalent, but for some dependencies, LATEST does not match any version, whereas [0,) does.
In my opinion they should be equivalent, but for some dependencies, LATEST does not match any version, whereas [0,) does.
In theory, LATEST is the latest released or snapshot version (see Rich Seller's excellent answer on the special RELEASE and LATEST versions) so I would indeed expect the same behavior as with the [0,) range. Out of curiosity, can you provide an example where LATEST doesn't match?
That being said, I don't recommend using the LATEST nor RELEASE special versions as they make your build more fragile and harm the build reproducibility (you don't really want your build to suddenly start to fail because of some uncontrolled update). Admittedly, they're considered as a bad idea and references have been removed from the documentation (except from an untranslated part of the German version of the Definitive Guide)
and they are no longer supported in Maven 3.x.
You are thus strongly invited to not use them at all (bad practice, deprecated, not supported in the next version).
And I somehow consider the same applies to version ranges (in general), I don't recommend them either as I wrote many times in previous answers or comments. See for example:
Managing maven dependancies - New Versions and Non-Repo libraries
Maven automatic SNAPSHOT update
Debugging Maven’s “The artifact has no valid ranges”
Follow-up after comment
Here's an example (among many):
<dependency>
<groupId>aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>[0,)</version>
</dependency>
-> matches version 1.5.3 Whereas:
<dependency>
<groupId>aspectj</groupId>
<artifactId>aspectjrt</artifactId>
<version>LATEST</version>
</dependency>
-> cannot be resolved
I'm not 100% but I don't think this artifact is providing the right maven-metadata.xml for this feature to work. I think metadata should include <release> and <latest> elements like for maven plugins (see for example this maven-metadata.xml). But I wouldn't spend too much time on this for the aforementioned reasons, just forget this LATEST stuff.
When you depend on a plugin or a
dependency, you can use the a version
value of LATEST or RELEASE. LATEST
refers to the latest released or
snapshot version of a particular
artifact, the most recently deployed
artifact in a particular repository.
RELEASE refers to the last
non-snapshot release in the
repository. In general, it is not a
best practice to design software which
depends on a non-specific version of
an artifact. If you are developing
software, you might want to use
RELEASE or LATEST as a convenience so
that you don't have to update version
numbers when a new release of a
third-party library is released. When
you release software, you should
always make sure that your project
depends on specific versions to reduce
the chances of your build or your
project being affected by a software
release not under your control. Use
LATEST and RELEASE with caution, if at
all.
See, for further information regarding this topic.
Make sure that the artifact you're looking for is present in your local repository.
However, I have to warn you about the LATEST and RELEASE version markers, as the documentation extract says, it is consider a bad practice to work with those. In fact, I think the LATEST and the RELEASE version markers will no longer be supported in Maven 3.X.
My recommendation is that you drop it usage completely and stick to the specific version notation.
EDIT:
Here is a POST that addressed this exact same information, but more thoughtfully.
Thanks to #Pascal Thivent for the observation :) I always include reference to the other StackOverflow questions that deal with the same subject I'm discussing.
Preface:
My Company, like most, has several run-time environments and several release versions which themselves are composed of different versions of various jars.
For example, let us consider release versions 1.1, 1.2, and 1.3 of Software X, which may be deployed to a developer computer, testing, or production.
Software-x-1.1 is itself composed of jarA-0.9.1 and jarB-0.7.5, but software-x-1.3 is composed of jarA-1.7.31 and jarB-0.8.1.
Currently we use Spring's PropertyPlaceholderConfigurer to configure run-time variables (such as database credentials), however, properties also change with release versions.
We also use Maven 2 POM version 4 to specify which versions of our code need to be used. We place the version numbers of our jars as properties within profiles (dev,test,prod) inside of the parent pom and then reference those version numbers in all project poms.
As of right now, we have no way to specify which project versions pertain to a given release other than the most current one. Moreover, we deploy our run-time configurations to the SSDM pickup which then configures and creates the services defined by the built versions of our software.
--
Questions:
Is there any procedure/tool we can use to build our product by merely providing the run-time environment and version number? IE "build 1.1 dev"?
Is there anyway we can store the required jar versions for each release build? We are currently versioning all files, including the parent pom, but merely versioning the parent pom does not record which release version is pertinent to that parent pom.
What else can we do to further automate the process of builds?
For example, if we could manage run-time configurations within the parent pom that would be a step in the right direction, but that seems like a violation of scope.
Any tool outside of our framework is inconceivable at this point, but not in the far future.
Summary:
How can we automate our build process to the fullest extent without being error prone?
Based on the part for released version 1.1, 1.2 and 1.3 of the Software X it seemed to be right way to use profiles to handle differences between test, production etc. environments.
The software itself is an other story. I assume you are using a version control tool (VCT) to store the state of your development. So during the preparation of Software-x-1.1 you change your root pom and define the dependencies (jarA-0.9.1, jarB-0.7.5). Make a Tag Release 1.1. and than continue to Release 1.2...during the development of Release 1.3 you decided to change the dependencies (to jarA-1.7.31 and jarB-0.8.1) which results in a change to the pom's or your root pom only). May be i oversight your real problem.
If I summarize your problem: you want to manage release of versions across multiple environments, and you release distribution is an aggregate of executable (jars) as well as environments properties. Different versions of these deploy-able distributions propagate to diff env at different stages with there own set of env properties and you are looking at a way to have a common roll out (or may be release process) to handle all of this.
It seems the first problem you have is that you run a build per release per environment when you are propagating a release. If I am not wrong, you should try looking at your app architecture first to see if there is a way you can create environment independent binaries, in some cases projects prefer keeping properties as a separate module which is deployed along with the jars, and a Property Manager of sorts which figures reads the files, so you may have a maven module called properties, which bundles one zip each for every env set of property files. Your deployer script can then be given a parameter while running on which zip file to extract to a location from where the properties can be read into the application. What you gain this way is that you "create one release distribution per release - which has contents to run on all environments".
Also, is it the case that you release version is "not" the version that you have in POM? if not aligning your release version to POMs should be done. i.e. POM should be 1.3-SNAPSHOT when you are working on development phase of that release, and be bumped off to 1.3 in a branch when you are releasing it.
There are no one size fits all solutions for such things but practices similar to this one do help to a good extent.
PS Do let me know if I got your problem right, or have ended up beating around the bushes ;-) DS.