Red Hat Bugzilla – Bug 1278072
AssetMgmt: Missing support for changing multi-project repository version
Last modified: 2017-12-07 18:38:23 EST
Created attachment 1089754 [details]
Build error stack trace in server.log
Description of problem:
1. Root pom.xml of the multi-project repository is not accessible from Authoring perspective (Project Explorer or Repository Structure). It can only be opened from File Explorer in Administration perspective and edited with a text editor.
2. After manually changing root POM version, using that version in <parent> section of the sub-module projects doesn't seem to work. Saving the project with parent project version set to 2.0.0-SNAPSHOT causes a build error "Parameter named 'value' should be not null!".
Version-Release number of selected component (if applicable):
With asset management enabled.
Steps to Reproduce:
1. Create managed multi-project repository with automatically configured branches.
2. Open root pom.xml in File Explorer, change version to 2.0.0-SNAPSHOT.
3. Repository Structure in Authoring perspective, add new module.
In step 3, version of the module cannot be changed, version 2.0.0-SNAPSHOT is inherited from the parent POM. After adding the module, error message appears in Messages panel.
1. The described steps to reproduce shouldn't result in a build error.
2. There should be a better support for changing repository version than text editing of the pom.xml in Administration perspective. The best place seems to be the Repository Structure screen and it would be nice if the version of all modules was changed together with parent POM version.
My understanding is that when there are a managed repository with multiple modules the user should never modify the pom.xml file manually, since there can be sub-modules, etc. And it's very easy break all the modules structure.
Aditionally, my understanding is that the version, is a kind "repository level" value, i.e., the child processes typically has all the same version. And this is why the version number for the sub-moules can't be changed.
So the version for given managed repository is changed typically by the relase process. When this process is excecuted a new version number can be specified.
But lets @salaboy confirm if the statments above are correct since I haven't work in the assets management time since a long time ago, and not sure if there has been changes or I've forgot something.
Today I also tryied to run the processes in 6.3.x build but it seems the are not working yet, by @salaboy was working on them so probably is still working on it.
Thanks Walter, upgrading repository-level version through completing of release process makes sense. I now understand why module version is read-only. I would then expect that the parent information in the module project editor should be read-only too.
Process instances and tasks are broken in ER5 (bz 1277473, 1277466) so I will try the project release in ER4 to see if repository version gets bumped.
Tried with ER4 and version and I get the described situation even after a successful release.
1. Releasing version 1.0.0 from release-1.0.0 will bump /pom.xml and /module/pom.xml versions from 1.0.0-SNAPSHOT to 1.0.0 (on the release branch). That can be handy if developers want to tag the release commit. However there is now (obvious way) to bump the snapshot version on master. I suppose that should include choosing what the next development version would be (e.g. 1.1.0 or 2.0.0).
2. After the release, module versions are bumped to the released version, but their parent version stays at snapshot. This could tracked in a separate ticket if you want to break this down into smaller pieces.
3. The parent POM (/pom.xml) doesn't seem to be installed after the release. After releasing version 1.0.0, repository version on the current release branch changes to 1.0.0. If I add a new module at this point, it will use 1.0.0 as its parent version and the build error "Parameter named 'value' should be not null!" appears in Messages.
Hi jiri, I could finally check it now with the app generated by Michael, and yes, I confirm that the release process is not bumping the parent pom.xml version as expected.
here's my understanding with reference to your notes above.
1- probalby something better can be implemetned for next version, but in my opinion not too much can be done for this version.
2. This is the bug, when the repository is relesed the version number should be bumped for the main pom.xml and their child projects pom.xml
3. This exception is because of 2. Since the release process should first build the parent pom.xml with the bumped version number and then the child processes.
2. and 3. should be fixed.
Employee 'firstname.lastname@example.org' has left the company.