The Maven Release Plugin's last step is release:perform, which checks out the tag created by release:prepare (as defined by the release.properties file), compiles, tests and packages the code and then... performs the release.
The docs state the following:
After the release is complete, the release.properties and other release files will be removed from the checkout.
Are the jars considered "other release files" and therefore deleted as well? If so, can this be disabled (I didn't see anything relevant in the command-line arguments)?
Related
I am trying to use maven to build a JNI project and I am running into some difficulty creating a GA release. The project's native code needs to be compiled on at least 3 systems (Linux, OSX, Windows) due to the native code requirements. I would also like GitHub Actions to produce a release build when I create a tag on GitHub. Because of this, I am facing a number of issues with the maven release plugin. It seems like maven's release process involves compiling and testing the code as well as screwing around with SCM before I can create a GA version and release. This simply isn't possible for this JNI project. I have already gone down the cross compiler route with Ant and I would really like to move away from that for any number of reasons, mostly Apple related. I also thought about releasing each JNI target individually, but I would really like to bundle the native code inside of the JAR and things start getting complicated when I need to share a .m2 folder across different build environments. Is it possible to release a maven project without all the compiling, testing and SCM nonsense? Maybe a different 3rd party plugin? Is there a better way I should be doing this? For reference, the pom can be found here.
Dont use the release plugin, I had a lot more success with the maven version plugin.
All the maven release plugin is doing is taking the version off the snapshot, creating a new commit and then upping the version to a new incremented SNAPSHOT. You can mimic this process without maven needing to know anything about your SCM using versions.
One way to do it is to not SNAPSHOTS and instead build with the git short hash as part of the version:
So while developing, the version looks pretty normal
<groupId>org.example</groupId>
<artifactId>my-app</artifactId>
<version>1.1.0</version>
The do a "release" build based on a tag. My flow was
commit and push
build - mvn clean install, results in my-app-1.1.0.jar
deploy to a test env and run regression tests, if they succeed, we tag the commit with a "passed_tests" tag
CI fires on tags that match "passed_tests" - this needed to be the same commit that resulted in the jar under test
runs mvn -f ./pom.xml versions:set -DnewVersion=${gitProps['git.build.version']}_${gitProps['git.commit.id.abbrev']}
On the disk, our maven version is now:
<groupId>org.example</groupId>
<artifactId>my-app</artifactId>
<version>1.1.0-abcdef</version>
then runs mvn deploy. This is the artifact that gets deployed to the repo and now we have a jar file (or whatever) that has a version matching the git commit.
You could use the same process for all your target architectures.
I'm trying to debug an Eclipse plugin that developed a bug around the 2019-09 timeframe. Something must have changed in the platform that causes it not to work anymore.
I can run the rcp 2018-12 distro and test it, and I verify that it works. I was able to step through the handler code.
If I run the 2019-12 distro, I can't fully compile the project, as it says "The type javax.inject.Inject cannot be resolved.". When I try to open type javax.inject.Inject in the 2018-12 distro, it finds it in "eclipse/plugins/javax.inject_1.0.0.v20091030.jar" in the distro. When I inspect that "plugins" directory, I find lots of separate plugin jars.
In the 2019-12 distro, it can't find javax.inject.Inject, and when I look in that plugins directory, I only find a single jar, the "org.eclipse.equinox.launcher" jar.
I remember this subject of the single launcher jar, but I don't know if this is a direct cause of this compile error, or what I have to do to move forward.
Update:
In response to the much appreciated answer, here's what I found:
I do find a ~/.p2 directory, and I found the javax.inject plugin in there. When I inspect the "Target Platform" settings, I see very similar information in both the 2018-12 and 2019-12 instance (plugin count varies by a very small number).
I inspected all of the MANIFEST.MF files, and none of them have a single "Import-Package" statement. I understand the advice is to add one, but I'd like to understand why I'm NOT seeing an error in 2018-12.
When I look at the "Plug-in Dependencies" list in the Project Explorer, I see "javax.inject" in the list in 2018-12, but I don't see it in 2019-12.
When I select the MANIFEST.MF file and view it in the form mode and select "Dependency Analysis" and then "Show the plug-in dependency hierarchy", I can then see that "org.eclipse.core.runtime", which is version 3.15... in 2018-12 and version 3.17... in 2019-12 has different dependencies. In particular, in 3.15, one of the dependencies is "javax.inject". In 3.17, that is not one of its dependencies.
So, I can see that a possible solution is definitely to add an "Import-Package" for "javax.inject", but can you explain why it might be that NONE of the MANIFEST.MF files have a single "Import-Package" statement as of yet?
If you are using an Eclipse installed with the Oomph installer the plugins can be in a different location (the .p2 direcory in your home directory I think). The javax.inject plugin should still be present along with all the other Eclipse plugins.
Plugins normally reference javax.inject using Import-Package in the MANIFEST.MF rather than specifying the required plugin use Require-Package so:
Import-Package: javax.inject
There haven't been any significant changes in this area between 2018-12 and 2019-12. The version of javax.inject is still exactly the same.
Check what you have configured as your Target Platform (Preferences > Plug-in Development > Target Platform) - that determines what plug-ins are available.
Update:
The reason you now need to add the Import-Package is the change made by Eclipse bug 487676 which removed the 're-export' of the javax.inject dependency from org.eclipse.core.runtime so that you now have to explicitly add it. This is also documented in the Whats New for Eclipse 2019-09 (4.13)
I'm converting a large project from Maven to Gradle. All of the projects, except for one, use java-library plugin.
One of the projects, let's call it build-info-impl creates a .jar. file with build.properties file with the current date, commit hash and other properties. The date, of course, changes every time a build occurs so that task is marked with outputs.upToDateWhen { false }.
Other projects depends on that build-info-impl using implementation dependency like so
dependencies {
implementation project(':mqm-server-root:mqm-infra-common:mqm-build-info')
}
The problem
When I build the projects the test task of all sub-projects always run. When I add --info I see the following output:
Executing task ':server-root:pom:platform-services:platform-services-impl:test' (up-to-date check took 0.017 secs) due to:
Input property 'classpath' file C:\Users\user\Documents\dev\project\gradle\Server\infra-common\build-info-impl\build\libs\build-info-impl-1.24.9-SNAPSHOT.jar has changed.
As far as I understand this means that the .jar file did get into the classpath even though the Java-Library plugin documentation clearly state:
Dependencies found in the implementation configuration will, on the
other hand, not be exposed to consumers, and therefore not leak into
the consumers' compile classpath
How can I debug why that .jar file ends on the classpath?
When I execute mvn release:prepare, I end up with two new files, release.properties and pom.xml.releaseBackup, and when I execute mvn release:perform, those two files do not get removed.
I've read up about the maven release process, and I understand that these files are not removed, and I understand why.
What I can't find out is whether or not those files should be checked in, deleted, or ignored.
Oops, they're not left behind. I had a problem in my POM, and the release failed. After fixing the POM and redoing the release, the files disappeared.
You can also run
mvn release:clean
To remove any left-over files.
I have a straightforward maven2 java project (JMS relaying system). After we released the first version, we found that we spent more time configuring maven than actually coding.
For the next release we wanted to clean up the build process and someone suggested migrating to builder. So I was tasked with doing just that.
I setup buildr (1.3.4) according to the documentation on their website. And then from the root of the project I typed the buildr command and then informed buildr to create the build file based upon my pom.xml. That processed fine and compiled all the code. All was gravy until buildr started running the tests. Here is the ouput:
Test framework error: taskdef class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask cannot be found
Obviously the class specified isn't in my classpath. However, the buildr documentation says that all the required items needed for basic testing are included. Their documentation doesn't say that they need any specific libraries for ant or a version of ant. Although I do have ant 1.7.0 installed (not included in my classpath however).
Has anyone seen this before?
Update
I located the infamous ant-optional jar on the maven repository. Including that in my test.with options did not resolve the issue.
Running the buildr command with --trace gives this extra information...
Tests failed!
/pathtoruby/buildr-1.3.4/lib/buildr/core/test.rb:455:in `run_tests'
/pathtoruby/buildr-1.3.4/lib/buildr/core/test.rb:199:in `initialize'
Found the issue... Apparently there is an ant-junit.jar that is needed but for whatever reason in my local repository it was owned by root and not my local user account (OSX system). So it wasn't accessible to buildr. I deleted the items from my local repository and reran buildr (it downloaded the needed items).
Update
Also this caused a few other issues. It seems that a few other items in my local repository had strange permissions. I ended up just archiving my repository and letting maven reconstruct it. This resolved all my issues. I now have a nice build file that is 25 lines of code compared to my previous pom.xml file that was over 100 lines.
You get that error because JUnitTask isn't on the classpath. I'm not very familiar with Buildr so can't say if it is required for you to specify the JUnit jars or not, but if Buildr uses the system classpath, try adding JUnit to it and see what happens.
Once you've confirmed your builds will run with JUnit hacked in to the classpath, you can then try varying your configuration until it runs as you expected, or leave it as is.
Can you post the reference to the relevant part of the documentation? I didn't see anything (in my very brief reading of the site) that says required items are included.
Is it possible that you've not downloaded all the gems? If you run "gem update --system" to update Ruby, then "gem update buildr" you can ensure that the required dependencies have all been installed.