I am using Lombok in my Tycho builds. I have a local copy of the lombok jar file on disk and point to it using jvm.config. It looks like this:
-javaagent:.mvn/lib/lombok-1.18.20.jar=ECJ
This works well, but contains a concrete version number, which can fall out of sync with the one used in the Maven build.
My question is: Is there a way to use a single version number from the Tycho environment (POM or target) to configure the lombok compiler and annotation library?
Related
I want to release a module via Jenkins that uses a dependency which is not only distinguished by its version but also by a custom classifier passed as a system property at build time. The effective pom printed in the console output shows that the correct classifier is used
<dependency>
<groupId>de.test</groupId>
<artifactId>common-module</artifactId>
<version>0.0.4-SNAPSHOT</version>
<classifier>custom</classifier>
<scope>provided</scope>
</dependency>
However, when the release plugins' prepare goal runs, the build breaks due to a compilation error because of missing classes which are only available in the dependency version that uses the custom classifier. Printing the properties with the maven-antrun-plugin reveals that the release plugin is using the version without classifier.
[INFO] [echoproperties] de.test\:common-module\:jar=/var/lib/****/.m2/repository/de/test/common-module/0.0.4-SNAPSHOT/common-module-0.0.4-SNAPSHOT.jar
[INFO] [echoproperties] maven.dependency.de.test.common-module.jar.path=/var/lib/****/.m2/repository/de/test/common-module/0.0.4-SNAPSHOT/common-module-0.0.4-SNAPSHOT.jar
I would expect the release plugin to pickup the jar named common-module-0.0.4-SNAPSHOT-custom.jar which is definitely available in the maven repository. Doesn't the release plugin support classifiers?
Problem solved. I found out that there are two issues. First, the module was also part of a transitive dependency, so maven tried to download a version without classifier that doesn't exist prior to the version containing the classifier. Second, the classifier was not passed to the maven release plugin. To pass system variables to the plugin one has to use the arguments option, so the actual command should be clean install -Darguments="-Dmy-classifier=custom" -Dmy-classifier=custom -B release:prepare release:perform. The system variable declaration must be redundant, one for the pom dependency and another for the release plugin.
I'm implementing unit tests for code used in a Jenkins Pipeline Shared Groovy Library. Specically, I need to mock the steps object available in the Jenkinsfile, which is an instance of org.jenkinsci.plugins.workflow.cps.DSL. In my Gradle build I've specified a dependency like so:
testCompile group: 'org.jenkins-ci.plugins.workflow', name: 'workflow-cps', version: '2.30', ext: 'jar'
which is the project hosting the class above. Without specifying the ext as a JAR, Gradle retrieves the .hpi file since this is the packaging defined in the project's pom.xml; obviously I need to override this and fetch the JAR for my project. However, in doing this Gradle does not download the transitive dependencies of the workflow-cps JAR and I find myself having to populate my build.gradle with all the dependencies determined via trial and error. Is there a way to retrieve the transitive dependencies, or is this a limitation of the workflow-cps project and how it defines its pom.xml?
The CPS class you're wanting to mock won't contain methods/variables introduced by plugins or your workflow lib, so this approach probably won't be fully satisfying.
Facing the same challenge I took the pragmatic approach of making my own TestScript interface in my test sources and Mock that, and not typing the script reference in classes.
The drawbacks are not having IDE code inspection for stuff referencing the script, and having to manually add signatures to TestScript as I add tests (which is also error-prone, since I have manually ensure that those signatures match).
But it works, and avoids getting dragged into plugin dependency hell.
I'm running sonar scan with following versions:
ant v3.0.5
sonar v4.5.4
sonar-ant-task v2.3
My ant project contains 100+ submodules; about half of them have external libs, and half don't
In my ant build file, following sonar properties are set:
sonar.projectKey = com.foo:bar
sonar.projectName = foobar
sonar.projectVersion = ${build.version.major}.${build.version.minor}.${build.version.subminor}
sonar.sourceEncoding=UTF-8
sonar.language = java
sonar.sources = src
sonar.java.binaries = build/classes
sonar.java.libraries = build/dependency/*.jar
Initial problem with above is that for the modules that don't have external libs, it fails since there's no jar inside /build/dependency after compilation.
According to this archive link: http://sonarqube-archive.15.x6.nabble.com/Analysis-aborts-because-of-quot-No-files-nor-directories-matching-lib-jar-quot-td5035215.html
I should be able to change the libraries property to
sonar.java.libraries = build/dependency/*
But this did not work for the combination of app versions i listed above. Using only "*" results in class not found error so i don't even think it correctly grabs the dependency jar files.
Could anyone advise if i'm using incorrect combination of the versions, or if this have regressed?
My current workaround:
Keep the "*.jar" as default project property, and add individual module's libraries property to the empty folder for those that do not have dependency jar. e.g.
module1.sonar.projectName=module1
module1.sonar.projectBaseDir=modules/module1
module1.sonar.java.libraries=build/dependency
module2.sonar.projectName=module2
module2.sonar.projectBaseDir=modules/module2
module2.sonar.java.libraries=build/dependency
... x 50 more of these
Is there more elegant solution?
thanks,
Scott
sonar.java.libraries property is handled by the SonarQube Java plugin. Please provide its version and if it is not the latest try to update.
You're on the right track. The analysis of Java multi-module projects is only easy for Maven users. :-(
I am new to ant and Ivy. We are using Jenkins for CI with ant for builds, Ivy for dependency manger. We have several modules/projects which generate jars and wars, which can be independently versioned and released (not all modules will be released at the same time), so, need to maintain version number separately for each module. We want to use the version format A.B.C.D (ex: 1.2.1.2). I found I can use a property file to enter a version number and use ant BuildNumber task to increment the number for our nightly builds. So, once all the features are in and tested we move the last successful nightly build as new released version but we want to change the version number without rebuilding it. For example last successful build was 1.2.1.20 and it was tested thoroughly and has all the feature, we have to make this build from 1.2.1.20 to 1.3.0.0 without rebuilding the modules. How can I do that using ant? And also I need to publish them to my shared repository with the version 1.3.0.0. How do I do that?
Also, we want to create a zip file for each module with all dependency files along with the module's jar file for delivery. Is there any ivy or ant tasks that can help to create this?
I think you've asked two questions...
Generally, every build I create is releasable so I'm always incrementing the last digit in my release number scheme. For controlling the version number I prefer to use the ivy buildnumber task, which increments based on what has been previously pushed to your repository (very useful).
Creating a zip package is quite straight forward. Just alter your ivy file to publish more than one artifact.
I'm trying to diagnose a failure in my ant file when it runs a Worklight task. I have a small ant file containing a simple reference to a Worklight task. This works correctly.
<target name="rawBuildApplication" >
<app-builder
applicationFolder="${applicationSource}"
environments="mobilewebapp"
nativeProjectPrefix="xxx"
outputFolder="${outputFolder}"/>
</target>
However when I invoke this ant file from a build control ant file (actually from the RTC build system) I get a failure (below), showing worklight failing to find an apache Java class. I assume there's some simple environmental difference, perhaps a classpath. It might help to figure it out if I knew where Worklight loaded the apache commons from. Right now I can't see anything in my environment in the case that works that points any apache Jar.
myAntFile.xml:146: java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.deleteQuietly(Ljava/io/File;)Z
at com.worklight.builder.util.BuilderUtils.<clinit>(BuilderUtils.java:672)
at com.worklight.builder.config.UserBuildConfiguration$Builder.<init>(UserBuildConfiguration.java:203)
at com.worklight.ant.builders.ApplicationBuilderTask.createBuildConfiguration(ApplicationBuilderTask.java:149)
at com.worklight.ant.builders.ApplicationBuilderTask.execute(ApplicationBuilderTask.java:80)
Edited: the cause is the use of -lib to add the RTC toolkit directory, exactly why this clashes and how to work around yet to be determined
Usually means you have version of the commons jar in your classpath, and its overriding the one packaged in the worklight-ant.jar. the apache commons files are inside the worklight-ant.jar file
Additional info from djna: I can confirm that when adding the Rational Team Concert (RTC) 3.0 toolkit to the ant classpath, either explicitly with -lib, or when selecting that option in the RTC Build definition some conflicting commons jars are added to the classpath. Worklight packages the classes it needs in its jar, but the -lib folder seems to take precedence.
My workaround is to replace the conflicting jars with later ones. I used these jars
commons-io-2.4.jar
commons-codec-1.8.jar
httpclient-4.2.5.jar
httpcore-4.2.4.jar
httpmime-4.2.5.jar
I guess the other alternative is to upgrade to a newer RTC, but in our environment that's not currently possible.