When using Maven, it's easy to look up latest version of SNAPSHOT artifact by going to parent's pom.xml:
https://github.com/apache/maven-compiler-plugin/blob/master/pom.xml#L33
But where do I look to get the same in Gradle?
For example I couldn't find any version in the sources here:
https://github.com/testcontainers/testcontainers-java
And if it's impossible, then why? How Gradle knows which version to build? Is this information external to the source code?
It depends on the project setup. The project you link to, according to their RELEASING.md, use the tag name for the version.
Create a new release on GitHub. The tag name is used as the version, so please keep the tag name plain (e.g. 1.2.3).
This is done by the Travis build script, .travis.yml, specifically the line
script: ./gradlew -Pversion=$TRAVIS_TAG release
Some projects will explicitly put a version=x.y.z in their gradle file, others will provide it explicitly on build (similar to the Travis script used).
The advantage of this setup is that the version is never in the script, and you can't get merge conflicts or accidental version overwrites on this.
Related
I am working on a project that I need to build a maven pipeline for versioning and release.
I am doing like this:
Change version manually by running mvn versions:set -DnewVersion=2.0.0.
Check the project detail and detect if it is snapshot or release. I have my own custom plugin and a parameter which returns the final version, e.g. 2.0.0-SNAPSHOT. BUT HOW CAN I return this value and feed it to another plugin?
I compile the project and generate the jar with new name, from 2.
And...
I know I can handle every step by a CL command but what I want to know and confused me is that how to embed everything in pom.xml and just run mvn install and nothing else.
Each plugin needs some arguments that should be able to change that. I know I can use the <argument> tag under <configuration>, but some of the plugins do not have the argument tag.
How can I have a solid solution and config everything in my parent POM beforehand?
Also I do have my own plugin but I am not sure if it is possible to embed all things to that and I just run myplugin:Install.
For building a SNAPSHOT, you usually just run mvn clean verify on your project. If you need special plugins, you can configure them in the configuration section following the advice in the plugin description.
For building a release version, you should use a build server (like Jenkins). There, you can construct all the steps much easier than in Maven. If for some reason, you cannot do that, use the maven release plugin.
Currently, my built structure for a plugin in is a bit messy: I'm using the normal IDEA project file to build the plugin locally. When I push it to the repo and travis-ci is building it, it uses the maven pom.xml because for travis to work, it always has to download the complete IDEA sources.
Although this works, this has several drawbacks:
I need to keep two built mechanisms up to date. This is
When a new IDEA version is out (every few weeks), I need to change the SDK in maven and in my IDEA settings
When I add a new library, change resources, etc. I need to do this for two the two settings as well
I ran into problems when I kept the IDEA Maven plugin turned on because it saw the pom.xml and interfered with my local built. Turning it off means, I cannot download libraries with Maven which has the feature of tracking dependencies.
I saw that Gradle has an 'idea' plugin and after googling, I got the impression that Gradle is the preferred choice these days. I have seen Best way to add Gradle support to IntelliJ IDEA and I'm sure I can use the answers there to turn my pom.xml into a valid build.gradle.
However, maybe someone else has already done this or can provide a better approach. What I'm looking for is a unified way to build my plugin locally and on Travis-CI.
Some Details
For compiling an IDEA plugin, you need its SDK which you can access through an installation of IDEA or a download of the complete package. Locally, I'm using my installation for the SDK. With Travis, my maven built has the rule to download the tar.gz and extract it.
It turns out that in particular for building an IntelliJ plugin, Gradle seems to have many advantages. This is mainly due to the great IntelliJ plugin for Gradle which makes compiling plugins so much easier. With Gradle, I could turn my >220 lines of Maven build into a few lines of easily readable Gradle code. The main advantages are that
It takes care of downloading and using the correct IDEA SDK while you only have to specify the IDEA version.
It can publish your plugin to your Jetbrains repository and make it instantly available to all users
It fixes items in your plugin.xml, e.g. you can use one central version number in gradle.build and it will keep plugin.xml up-to-date or it can include change-notes
It seamlessly integrates with Travis-CI
How to use Gradle with an existing IDEA plugin
Do it manually. It's much easier.
Create an empty build.gradle file
Look at an example and read through the README (there are many build.gradle of projects at the end) to see what each intellij property does.
Adapt it to your plugin by
Setting the intellij.version you want to build against
Setting your intellij.pluginName
Define where your sources and resources are
Define your plugin version
Define a Gradle wrapper that enables people (and Travis) to build your plugin without having Gradle
Create the gradle wrapper scripts with gradle wrapper
Test and fix your build process locally with ./gradlew assemble
If everything works well, you can push build.gradle, gradlew, gradlew.bat and the gradle-folder to your repo.
Building with Travis-CI
For Travis you want to use the gradlew script for building. To do so, you need to make it executable in the travis run. An example can be found here.
Recently, a project I need as a dependency for some of my programs has switched to providing patch files instead of actual jars (legal reasons).
They included a small tool to automatically patch your existing jars with the new update you downloaded.
I could write a small program that automatically downloads and patches the file, all I need is a way to tell maven not to download the file but to run a command and then use the file from my local repo.
Is there a way to do this (maybe using a custom plugin)?
You could write a small ant task run the tool and call this task from your maven build using maven-antrun plugin.
You could also write your own maven plugin but for such a simle task I would not recommend it.
The reason why your IDE does not find the dependency is that it is not published anymore (not the version you seek apparently).
Building the artifact and installing it locally as #Joe suggested is an elegant solution to solve your issue from my perspective.
The advantage is twofold:
Your IDE can seamlessly find the missing artifact
You can keep multiple version of that dependency (one for every new patch) and thus reproduce previous (working) build in case a new patch breaks something.
if you have a local repository, it is even better as this would maven the dependency available to all your team.
Of course you would still need a tool to download new patch, apply them and deploy the produced artifact to the repository automatically. But doing this as a separate task give you more flexibility concerning the tools you could use.
I have a problem concerning target definitions in Eclipse. I want to use plugin version 1.0.0, which is in my target platform definition, while I have the plugin project in my workspace with version 1.0.2. For all other plugins in my target definition, everything works as expected (which I see because an error gets flagged if something's missing), but this specific one, Eclipse does not make available to my projects. Only the plugin version 1.0.2 is. The plugin is not set as a singleton.
Why is this and how can I resolve this problem?
I figured out that I can access the right version when I close the project that contains the wrong one - but this is awkward, is there another way?
It seems that it's actually not an eclipse-specific problem, it fails also when building on the command line through maven/tycho. Specifically, my target platform is the Juno Release. Are there plugins that, while part of a feature, are not made available to other bundles? I know the plugin is there, but neither tycho nor Eclipse want to make it available to me.
Maybe I should also say it fails at compile time.
While, as I said, there exist workarounds for the problem, I still would like to have a "nice" solution to this problem. You can check out the project together with the target definition at https://github.com/kutschkem/Jayes
You may also need to check out and build this project first:
git clone http://git.eclipse.org/gitroot/recommenders/org.eclipse.recommenders.git
After setting the target platform, try building something with Jayes 1.0.0 (which is in the target platform) instead of Jayes 1.0.2 (which is in your workspace). You can also try to build with maven, it doesn't work as well.
Known workarounds:
Close the Jayes 1.0.2 project. Then, eclipse lets you use Jayes 1.0.0
For running an (OSGi) application, you can choose which bundles are loaded. You can choose version 1.0.0 manually there
Using a product definition, you can access the same runtime configuration as for workaround 2
If someone finds a workaround for maven, I'd be happy to know about it.
Maybe you have set your plugin to be singleton, so there will only be one instance for the bundle with a specific id.
You can change this by remove the "singleton:=true" in your MANIFEST.MF.
Bundle-SymbolicName: org.eclipse.xxx; singleton:=true
Or, you could remove the 1.0.2 version plugin from the run configuration when start running. click run --> run configuration to open the run configuration dialgo, switch to 'plugins' tab, here you can select which of these plugins you want to use .
I think you have already tried the following, but a reload of the target platform might help.
Also, what does your feature.xml file specify for version of that plugin?
I recently tried to use maven-release-plugin since it is apparently the recommended way of building and packages releases in the Maven universe.
However I wanted to use this within Eclipse, as the rest of my development workflow is Eclipse based. I normally run Maven commands via the m2eclipse plugin provided as part of Eclipse Juno (4.2)
I noticed a few oddities when I tried to run "release:prepare" within Eclipse:
Some extra files were created in the root project directory - "pom.xml.releaseBackup" and "release.properties". Do they really belong there? Have I got the release directories set up correctly? I wouldn't really consider these temporary artifacts as part of my source code tree......
The pom.xml gets manually overwritten with the updated release number. Eclipse warns you and is happy to reload the updated version - but is this generally safe?
The prepare ultimately fails giving the error [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.0:prepare (default-cli) on project clisk: Failed to invoke Maven build. Error configuring command-line. Reason: Maven executable not found at: C:\Users\Mike\git\clisk\EMBEDDED\bin\mvn.bat -> [Help 1] - presumably because I am using the built-in Maven excetable provided by m2eclipse rather than the command line. I guess I could install command line maven as well.... but is that sensible or will it just cause more problems?
Given these kind of issues, Is there a way to get maven-release-plugin to work smoothly within Eclipse, or should I just give up and continue to do releases manually?
I have been using release plugin, but only from command line.
Re. 1. The backup files that release plugin creates are needed if something goes wrong in time of preparing the release. You can always rollback the prepared release using release:rollback command. When you do release:perform they will be deleted.
Re. 2. The plugin changes the version number from snapshot version for example: 0.0.1-SNAPSHOT: to release version: 0.0.1. Then after release:perform release version is moved to the maven repository and release plugin changes version again to 0.0.2-SNAPSHOT. Now you can use you full released (tested) version in your testing or production enviornment and snapshot version for developping purposes.
Re. 3. I don't know what is causing the problem, but I don't see the problem by using release plugin from command line.
Also mvn 3.3.3 installs a mvn.cmd file, instead of a mvn.bat file in Windows.
You should copy mvn.cmd to mvn.bat
Well i know this link is OLD , but to help some on who reffers this link for the issue 3.
Install maven separately on to local Box and give the path of the installation under Windows->Preferences--> maven--> Installation. Also you have to define the same in the run configuration within the Eclipse.
Attached is a link that explains the same.
http://maven.40175.n5.nabble.com/Build-Failure-prepare-release-td510949.html
You might be able to overcome the error you mention by installing command line Maven and configure Eclipse to use that rather than the embedded one by choosing Window -> Preferences -> Maven -> Installations, but I agree with the advice of making your releases outside Eclipse.