I was able to build a cordapp using Accounts by following the steps at https://github.com/corda/accounts.
This cordapp was building and running until 03/16/2020, but since 03/20/2020 I am seeing errors in my CI builds because https://ci-artifactory.corda.r3cev.com/artifactory/corda-lib-dev/com/r3/corda/lib/accounts/accounts-contracts/1.0-RC04/accounts-contracts-1.0-RC04.jar cannot be accessed. I get a 409 response now, how can I resolve this?
{
"errors" : [ {
"status" : 409,
"message" : "The repository 'corda-lib-dev' rejected the resolution of an artifact 'corda-lib-dev:com/r3/corda/lib/accounts/accounts-contracts/1.0-RC04/accounts-contracts-1.0-RC04.jar' due to conflict in the snapshot release handling policy."
} ]
}
My build.gradle has
accounts_release_version = '1.0-RC04'
accounts_release_group = 'com.r3.corda.lib.accounts'
confidential_id_release_group = "com.r3.corda.lib.ci"
confidential_id_release_version = "1.0-RC03"
repositories {
maven { url 'http://ci-artifactory.corda.r3cev.com/artifactory/corda-lib-dev' }
maven { url 'http://ci-artifactory.corda.r3cev.com/artifactory/corda-lib' }
}
My local builds on my development environment work fine, I assume because I already have the jars in my .m2
Artifactory configuration has been changed to enforce separation between release and snapshot repositories. corda-lib-dev is a snapshot repo and CorDapp developers should not be developing against these.
Releases and release candidates will be available in corda-lib going forward.
Kindly use corda-lib, and develop again release 1.0.
The pom file with RC04 is set to return 409. I assume Corda's way to disallow use of RC04. May be RC03 is also the same. I just tried this today and saw the repository pom files.
Use "1.0" instead of "1.0-RC03"
Related
We have a Java app that was built using 2017 version of JFrog java services jar. Today I am trying to rebuild it using latest jfrog lib. I see that the new services jar doesn't have org.apache.* packages in it.
This is how I built jfrog services jar.
Downloaded 2.8.6 source zip and expanded it
Upgraded gradle to latest and ran "gradle clean build -x test -x javadoc"
Then copied services/build/lib/*services-2.8.6.jar ONLY to my project lib folder
When I try to build, I see so many compilation errors. The old lib was called something like artifactory-java-client-ning-services-1.2.0-all.jar.
How do I build one like it?
Update on 11/6/20 after Dror responses below:
I changed the build strategy to point to jcenter to download and create uber jar with all the dependencies with gradle file like below. I am still running into missing classes.
Below is one of those errors:
error: package org.jfrog.artifactory.client.ArtifactoryClient does not exist
import org.jfrog.artifactory.client.ArtifactoryClient.ProxyConfig;
In Netbeans IDE that I am using, I can expand each package in a jar and see the classes in it. I don't see anything under org.jfrog.artifactory.client package. That is strange.
My build.gradle:
group 'org.jftog.example'
version '1.0-SNAPSHOT'
apply plugin: 'java'
sourceCompatibility = 1.13
repositories {
jcenter()
}
dependencies {
compile 'org.apache.commons:commons-collections4:4.4'
compile group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.3'
testImplementation group: 'junit', name: 'junit', version: '4.12'
implementation 'org.jfrog.artifactory.client:artifactory-java-client-services:+'
implementation 'org.jfrog.artifactory.client:artifactory-java-client-api:+'
}
jar {
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA'
}
Update on Nov 10th 2020:
I found that the artifactory sdk changed and I was using stale classes. I fixed those references in my classes to use newer SDK counterparts and the issues were gone.
I ended up using following gradle file to build everything I needed:
group 'artifactory-client-sdk'
version ''
apply plugin: 'java'
sourceCompatibility = 1.8
buildDir="${rootDir}/../out/artifactory_client_sdk"
def signbridge_lib="${rootDir}/../libs"
jar.baseName = 'artifactory-client-sdk'
repositories {
jcenter()
}
dependencies {
implementation 'ch.qos.logback:logback-classic:1.2.3'
testImplementation group: 'junit', name: 'junit', version: '4.12'
implementation 'org.jfrog.artifactory.client:artifactory-java-client-services:+'
implementation 'org.jfrog.artifactory.client:artifactory-java-client-api:+'
}
jar {
from {
configurations.runtimeClasspath.collect { it.isDirectory() ? it : zipTree(it) }
}
exclude 'META-INF/*.RSA', 'META-INF/*.SF','META-INF/*.DSA','**/org/jfrog/example'
}
task copyJar(type: Copy) {
from jar // copies output of file produced from jar task
into "${signbridge_lib}"
}
build.finalizedBy copyJar
Thanks a lot to Dror for great pointers!
The sources of the Artifactory Java client can be found in the jfrog/artifactory-client-java GitHub repository.
The services module used to be built as an uber jar containing 3rd party dependencies. On Oct 2019 the build has changed to create a thin jar instead of an uber jar.
To solve you issue you can either:
Include the 3rd party dependencies of the service module when building you application
Revert the change in build.gradle and continue to build an uber jar
Instead of building from source, you can consume the artifact from jcenter where is it being published by JFrog. The artifacts are published together with Maven .pom files which contains all the required 3rd party dependencies (all of them are available in jcenter).
In addition, there is an example Github project which shows how to consume the client library using Maven or Gradle.
I am currently working on a Gradle custon plugin that should analyse my root project for specific configs in every subproject and then generate some kotlin source code in the build dir. I can't figure out a way to invoke my annotation processor from my gradle plugin which has a custom task for this matter.
Any ideas how to achieve this? Any resource/tutorial/documentation is also highly welcomed.
Thanks in advance and be safe.
After a long time of googling and mostly trying and failing, I finally figured out the solution to my question. Here is my task configuration.
Basically we have to provide the annotation processor's classpath as a project configuration. In my case I added this block to the project's build.gradle
allprojects {
configurations {
myProcessor //pick any name!!!
}
}
and then as a dependency in app build.gradle
dependencies {
myProcessor "PATH_TO_MY_PROCESSOR_JAR" //or maven dependency if it's uploaded to maven central
}
tasks.register(
"myTaskName",
JavaCompile::class.java
) {
compiler ->
with(compiler.options) {
isFork = true
isIncremental = true
}
with(compiler) {
group = shuttle.plugin.ShuttlePlugin.TASK_GROUP
destinationDir = outputDir
classpath = variant.getCompileClasspath(null)
options.annotationProcessorPath = configurations.getByName("myProcessor") //this is the missing piece!!
source = files(projectDir.resolve("src/main/java")).asFileTree
}
}
However, this task will only compile Java classes Only and not kotlin.
Any Idea how to fix this behaviour knowing that my plugin targets only android apps so I don't have direct access to kotlinCompile gradle default task?
I'm trying to install a demo shop of Intershop version 7.9 but i'm failing to get it working. When I run "gradlew deployServer" I'm getting an error on all dependencies of the first demo shop cartridge:
Could not resolve all dependencies for configuration ':app_sf_responsive:compile'.
Could not resolve com.intershop.business:ac_ecircle:.
Required by:
nl.test.testproject:app_sf_responsive:1.0.0-LOCAL
No version for module 'com.intershop.business:ac_ecircle' in project properties and no version declared in dependency. Consider adding a version or filter property to 'C:\projects\test7.9\projects\testproject\gradle.properties'
I have followed the complete Intershop manual Setup CI Infrastructure but there is one point I don't know exactly what to do, that's with the new versioning plugin.
It is in chapter 6.2.5, any one have an idea how to configure that?
After loads of tinkering and mails back and forth with Intershop support I found a solution.
My alterations are in section 7.2.4 of the Setup CI Infrastructure of Intershop:
https://support.intershop.com/kb/index.php/Display/279D85#Cookbook-SetupCIInfrastructure-CorporateArtifactsRecipe:SetupCIBuildforCorporateArtifacts
I Made sure the corporate distribution is unique since I have more that 1 Intershop installation. Otherwise the upload to Nexus(in my case) will still fail.
In the build.gradle of the corporate distibution folder added disableSCM = true in the scm.version section. It now looks like this:
scm {
version {
type = 'threeDigits'
increment = 'MAJOR'
patternDigits = 1
disableSCM = true
initialVersion = '2.0.0'
}
}
If this is not added I got a bad request httpstatus 400 from Nexus because it tried to upload it as a snapshot while the distribution repository is a release repository.
Another problem is the distributionURL in the project/gradle/wrapper/gradle-wrapper.properties
All Nexus repository URL's are build up with < repoBaseURL > + repositories/snapshots, but the distributionURL is missing the repositories part.
After applied those changes it worked for me.
We have an internal Nexus repository that we use to publish artifacts to and also to cache external dependencies (from Maven Central, Typesafe, etc.)
I want to add the repository as a resolver in my SBT build, under the following restrictions:
The settings need to be part of the build declaration (either .sbt or .scala, but not in the "global" sbt settings
If a dependency exists in the local repository, it should be taken from there. I don't want to have to access the network to get all the dependencies for every build.
If a dependency doesn't exist locally, sbt should first try to get it from the Nexus repository before trying the external repositories.
I saw several similar questions here, but didn't find any solution that does exactly this. Specifically, the code I currently have is:
externalResolvers ~= { rs => nexusResolver +: rs }
But when I show externalResolvers the Nexus repo appears before the local one.
So far, I've come up with the following solution:
externalResolvers ~= { rs =>
val grouped = rs.groupBy(_.isInstanceOf[FileRepository])
val fileRepos = grouped(true)
val remoteRepos = grouped(false)
fileRepos ++ (nexusResolver +: remoteRepos)
}
It works, but is kinda dirty... If anyone has a "cleaner" solution, I'd love to hear it.
I followed the upgrade notes to upgrade from Artifactory 2.6.6 to 3.4.2, I reimported the artifacts but after that, artifact resolution often fails with 404.
Even previously deployed artifacts can not be resolved. The deploying Jenkins job runs fine, but when I open the URL from the log, I get that message:
{
"errors" : [ {
"status" : 404,
"message" : "Artifact not found: my/group/myapp/0.9.13-SNAPSHOT/myapp-0.9.13-SNAPSHOT.pom"
} ]
}
I also tried to export/import the whole system after upgrade, but nothing changed.
Does anyone know how to fix this?
I found out that the issue is related to the unique snapshot behaviour of Maven 3. In fact, there is no myapp-0.9.13-SNAPSHOT.pom, but one with a timestamp. The Rest API does not cover that and not all Jenkins plugins have support for that.