We are having a domain project and there are 8 other projects which have a dependency on it.
Every time, when we do some changes to the domain project we have to increment the snapshot version and also increment all child projects manually which is a huge pain.
Is there a better way to auto-increment the version in the domain project during every update and also to update all other child projects referring to it automatically?
<groupId>com.xyz</groupId> <version>1.1.0</version>
the same version has to be updated in all other child projects referring to it.
Since Mule 4.2.2 domains can be referenced using semantic versioning, so you don't need to update the applications that reference that domain. You can deploy the new version of the domain with an increased version, and Mule applications will accept it as compatible if it has a higher version.
From the documentation topic Associate Applications with a Domain:
The version honors semantic versioning.
For example, if you set the version to 1.0.1, a domain with version 1.0.2 > and later works, but a domain with version 1.0.0 does not.
Related
What is the recommended way of upgrading the quarkus version used in an existing application?
I have taken a look at my pom.xml, since the quarkus extensions dont specify the version used, I assume that they will get updated based on the main quarkus version.
The properties which look to be relevant in the update are quarkus-plugin.version, quarkus.platform.group-id and surefire-plugin.version.
How can I decide which ones to change, and is there anything else to be aware of?
There is one important thing to know, we have:
Quarkus Core: this is the main Quarkus artifacts + all the core extensions: the quarkus-bom is the one of Core. The Quarkus Maven plugin is part of it too.
Quarkus Platform: it contains more extensions such as Camel Quarkus: the quarkus-universe-bom is the one from the Platform, it contains the Core + the additional extensions
We usually release Quarkus core then Quarkus Platform with a few days between the two as we often need a release of Camel Quarkus, which is an Apache project and organizes a 72 hours vote for each release.
In a newly created project, you have the following properties:
<quarkus-plugin.version>1.1.1.Final</quarkus-plugin.version>
<quarkus.platform.artifact-id>quarkus-universe-bom</quarkus.platform.artifact-id>
<quarkus.platform.group-id>io.quarkus</quarkus.platform.group-id>
<quarkus.platform.version>1.1.1.Final</quarkus.platform.version>
quarkus-plugin.version is the version of the Quarkus Maven plugin, it should be in line with the version of the core you use
quarkus.platform.artifact-id can right now either be quarkus-universe-bom for the whole Platform or just quarkus-bom for the Core only.
quarkus.platform.version is the version of the BOM.
Usually all these versions should be aligned. But... it could happen that we would need some quick update in the Platform and not of the core and we could then only release a new version of the platform. This hasn't happened yet to be honest.
Let's take an example of what happened today: I released Quarkus Core 1.2.0.Final but we are still waiting for Camel Quarkus to be released to release the Platform.
If you want to update early, you can change the BOM to use the quarkus-bom and update everything to 1.2.0.Final.
Or you can wait for the Platform to be released early next week and stay on the Platform quarkus-universe-bom.
We also only update the website documentation and code.quarkus.io when the full Platform is released.
It used to work to simply issue the command
mvn io.quarkus:quarkus-maven-plugin:1.4.2.Final:create
in the base project directory for it to automatically update the Quarkus versions in the project pom.xml file, but since 1.6.0.Final it errors:
project XXXXX: Unable to generate the project in a directory that already contains a pom.xml -> [Help 1]
I will create an improvement suggestion ticket at Quarkus to restore this functionality, maybe with a dedicated maven goal (like update)
I've got multiple projects using a certain Dependency of Version XX, if I release a new version, I have to touch every project to change it to version XX.Y.
I've came across an approach to edit my m2 settings <version>${my.version}</version>, to add a parameter and bind it into my POM.xml, but this implicit means, everyuser has to manage their m2 settings when I do a new release.
Is there a way to central (user independant) manage the versions as in SVN, so none has to change anything and it always uses the up2date version, if I release a new version?
In general, the maintainer of every project should decide for themselves if they update the version or not. Updating the version might break things, so they may choose to stay on the older version. Particularly, it is important that the maintainers notice that something has changed, so that tests are run.
For development, though, there are Snapshot versions. A Snapshot dependency always references the newest version, but the -SNAPSHOT indicates this to the maintainer of the project. Snapshot versions should not go to production - the builds are not reproducible.
If artifacts are so tightly coupled that they are build together, think about using multi module projects.
You can use a pattern called "Bill of Material".
I think your question is somehow similar to this question (but not exactly a duplicate), and my answer applies here aswell:
You create a new maven project (the bill of material) that only consists of a pom with dependency management block. Here you declare all your dependencies and their versions. The packaging should be set to pom.
This bill of material (bom) project is now used as parent of all other projects. When using a dependency, only group id and artifact id is specified, the version tag is ommited. In that way, the version will be taken from the bom and you have one central place to manage the versions of the dependencies.
More details with examples are here (in the lower part of the page) or here.
Consider a project that is used in other projects, and this project has version 1.0 and is present in the Nexus.
After that, some changes are done in this project.
Now there are two solutions:
Increment the version of the project to 2.0, and delete the version 1.0 from Nexus. When the developers try to get the dependencies from the Nexus with version 1.0 they will get an error that this version does not exist and need to change the version to 2.0.
Change the functionalities of this project and inform the crew that some changes are done, but this is not the practice at all.
Is there any functionality in Maven and Nexus to simplify this task and make this all happen in the backend so the developers can't do anything, or is this not possible?
If you have an old version of an artifact that must not be used anymore because it has some dangerous bug, or it does not work with the new database structure or something like this, it may be advisable to move it to some non-public Nexus repository (and also delete it from the local repository of the build server), so that nobody can use it for release builds (people can use it for local builds, but this is usually not dangerous).
If you want to manage standard versions throughout your company, it is a good idea to have a parent pom or some boms which collect versions in a <dependenyManagment> section and can be included by the developers. This way, you only need to inform them to change one version number (namely the one of the parent pom or bom) instead of many.
Still, you are left with the problem that people do not read company newsletters. I know the problem that many developers of jars compile and test their source code against very old versions of their dependencies while the war/ear (that includes the jar) uses new versions.
We are using mvn pom.xmls to specify interdependency between our various modules that make up the project.
The numeric version for every module is incremented by the build system automatically when the module is released.
However, in this case, this would necessitate notifying every team to update the version their module depends on to the version we just released.
Can Maven instead just work in a way that users of a library specify something like, "depend on the 'STABLE' version of this module", and then with every build it would figure out which actual version number that translates to?
Why don't you just depend on the major version, and release minor versions?
<version>[1.,)</version>
You can also use RELEASE
<version>RELEASE</version>
However I guess that's not supported in Maven 3.
See more discussion about the same topic from this thread.
I have an Eclipse 4 project that is built using Tycho (0.19.0) and Maven (3.0-5)
During development of a version, say 1.0.0, the artifacts are configured with version 1.0.0-SNAPSHOT, and 1.0.0.qualifier depending on the files. When I want to release the version, I use the tycho-versions:set-version goal to change from 1.0.0-SNAPSHOT to 1.0.0.
I then build and copy the product to a remote share that publishes an update site so that older versions can be upgraded automatically at launch time.
Since I have some beta testers, I use more that one update site. One contains the stable versions, and my beta testers have one more update site to check at startup. The other one is actually an update site for snapshots that I have published, so those are not released versions of the product.
What I am experiencing seems strange: When the 1.0.0 application starts, it finds the previous snapshot (versioned 1.0.0.201312191455), thinks that those artifacts are more recent and updates itself back to an older version.
I'm guessing that Eclipse's version conventions state that x.y.z is older than x.y.z.u. Is that correct?
If so, then why does the tycho versions plugin remove the qualifier when a versions changes from snapshot to "release"? Doing so seems to make the artifacts look older than any of the snapshots. What's the correct way to handle this situation?
The answer was given in the tycho mailing list some time ago:
http://dev.eclipse.org/mhonarc/lists/tycho-user/msg01001.html
The details:
OSGi does not have a notion of "snapshot" versions, all versions are
treated the same and 1.0.0.qualifier is indeed considered to be newer
than 1.0.0.
There are two versioning schemes that result is reasonable behaviour
both for OSGi and Maven.
Use the same four part version (eg., 1.0.0.20111112-0735) for both Maven
and OSGi. This results in slightly odd version jump when going from
snapshots to releases on the maven side, i.e. 1.0.0-SNAPSHOT goes to
1.0.0.20111112-0735, but everything works otherwise.
Use even/odd convention to version snapshots and releases, i.e.
1.0.1-SNAPSHOT/1.0.1.qualifier is released as 1.0.2/1.0.2.
I think it is also possible to decouple maven and osgi versions of
released artifacts, i.e. use 1.0.0 for maven and 1.0.0.20111112-0735 for
OSGi, but personally I find this confusing and would not recommend. And
I am not sure if Tycho will allow this in the future.
--
Regards,
Igor