I published a Scala library in Bintray, for Scala 2.11 and 2.10
But in JCenter, it is only available the Scala 2.10 version.
I thought that it was in sync automatically, but looks like I was wrong.
Any idea how to sync both repositories?
Usually when changing the artifact path you won't be able to resolve your content through JCenter although it was previously included.
The reason for this is that the inclusion of your scala library in JCenter is for the files’ path.
Therefore, it was originally included under the path prefix 'com/acervera/osm4scala/osm4scala-core_2.10'.
However, we have re-linked your scala library on the GroupId level so your versions will be synchronized automatically:
'osm4scala-core_2.10', 'osm4scala-core_2.11', etc..
Guy.
Related
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.
Here I read about how to make a Groovy library .jar ... i.e. pretty much the same as making a Groovy (standalone) project. But I'm not clear what you do then with the resultant .jar...
Say I have two Eclipse "proper"/"standalone" projects (I'm using Groovy for everything) and I want them to share a third Gradle library project of mine as a dependency, which is merely a library of classes... how are my standalone projects expected to find the latest .jar version of the library which they're both using...?
My expectation would be that somehow these versions of the library .jar would have to under GRADLE_USER_HOME (i.e. same location as all other dependency .jars).
Then I would assume that in the build.gradle of both standalone projects you'd have a line like
compile 'mylibrary:mylibrarymodule:3.+'
... of course the first part of these compile directives normally involves a "domain name in reverse" ... and this is normally used by a repository like Maven. How does it work with something which doesn't need to be published?
NB at the time of writing I don't have a Maven account as such and have no idea whether "publication" for re-use of a local common library project like this is essential or not.
Naturally, when I distribute versions of my standalone projects they will need to be packaged up with the library .jar in question.
A link to a how-to for a case like this would be more than welcome: I haven't found it under gradle.org.
If you are developing by yourself, you can use maven-publish plugin to publish your artifacts to local maven repository(you don't have to install maven for this) and on your dependent project you can simply say use mavenLocal repository for dependencies.
If you are on a company, I suggest installing a repository manager and deploy your artifacts to this repository so others can use. You can use their respective plugins to deploy easily. (Gradle Artifactory Plugin, Gradle Nexus Plugin, these are just deployment plugins, you have to setup respository manager to. There are other repository management tools also.) Doing the above process from CI server is the preferred way.
To use latest version of a dependency, you can use Gradle Versions Plugin. If the versioning happen often, using snapshot versions also a possibility.
i have following requirement.
i need to download the latest version of artifact from custom nexus repository rather than snapshot repository.
please suggest
Thanks.
To get the latest version of any artifact, just omit the <version> tag from the dependency. This way maven will always fetch the latest version of this artifact from the remote repo.
Warning: Keep in mind that this is not the preferred way to handle dependencies nor it is the proper flow of dependency management. By keeping the version number open ended, there is a very high probability that your project may fetch a particular version of any library that is now not backward compatible and may break your functionality in the project. It is, therefore, always recommended to specify a particular version number of all artifacts that are required for any application and when updating any library version, one should properly test it.
EDIT
For maven3 you can use the facility of an open ended version tag. Something like this
<version>[1.12.4,)</version>
Take a look into this page for further details about version ranges
According to this issue: https://issues.apache.org/jira/browse/MNG-3092 snapshots cannot be excluded (at least until this is fixed).
I'm trying to fork a discontinued maven library that is already in the main repository.
What are good guidelines to follow when doing so?
Should the groupId/artifactId be changed so that it doesn't clash with the library that's already in the maven repository?
This library will be a dependency to a project that will also be available publicly(in the maven repo) so this library should also be there.
The modifications add improvements and some changes on how the library works, so I would like it to be separate from the old versions.
Sonatype recommends you change the groupId when you fork a project.
B2) upload them under your the forked project
groupId (presumably one you own and appropriate for the fork)
I assume you are forking the other project for internal use? Then I would keep the original groupId/artifactId but add a postfix to the version. If the upstream version is 1.0.0 your custom version would be 1.0.0-custom.
If you create a public fork then you basically have to use a new project name and so a new groupId/artifactId.
Maven repositories contain these two dependencies: org.apache.commons:commons-io:1.3.2 and commons-io:commons-io:1.3.2. What is the difference and which one I should be using in my pom.xml?
In general some of the apache commons packages are located in http://repo1.maven.org/maven2/org/apache/commons/ and most of the commons-* packages are located here http://repo1.maven.org/maven2/.
The deployment of
org.apache.commons:commons-io:1.3.2
Was a mistake that was ultimately fixed by relocating:
POM of org.apache.commons:commons-io:1.3.2
To use commons-io:commons-io:1.3.2.
The mistake was likely an attempt to migrate the Commons IO library to use the current naming convention for Maven groupIds.
From commons-io website. the latest release is 2.0.1. 1.3.2 is pretty old. Given this information, the repository in http://repo2.maven.org/maven2/commons-io/ holds the latest releases and is the right one to use.
This related mail thread makes interesting reading.
The two dependencies look the same. I would prefer to use commons-io:commons-io, cause the pom of org.apache.commons:commons-io:1.3.2 is wrong (wrong groupId!)
The artifacts located at this position: http://repo1.maven.org/maven2/org/apache/commons/ are newer in date than the others.