Update panc version used by unit test

[quattor]

Update panc version used by unit test

[stdweird]

i would like to vote for 10.1 or later; since i'd like to use that one for the metaconfig unittests (the sole reason for that being that it has a working includepaths option; nothing to do with language features)

[jouvin]

The version used to be specified in cfg-module/src/main/resources/archetype-resources/pom.xml but this seems to be no longer the case. Are we just taking the last version available on the nexus server? The version used is currently 9.3. Does this mean that panc-maven-plugin 10.x has not been pushed to the nexus server?

[jouvin]

@stdweird for the metaconfig unit tests, you definitely need 10.2 whose main feature is the ability to have variable in the path of bind statement to be able to use a variable path. An example is:

bind '/software/components/metaconfig/services/{${GIP_CE_MAUI_PLUGIN_DEFAULTS_FILE}}/contents' = maui_plugin_ce_defaults;

Note that it also allows to use {} to escape the corresponding part of the path, even if it is a variable.

[stdweird]

none of those should go into metaconfig templates if it's up to me. it's not worth the effort, but different discussion.

[jouvin]

Sure it should not go into the templates but we need to be able to test it... And if it is not in metaconfig templates themselves, it will be in the template library... The main point is that I don't see any reason to stay with 10.1 rather than 10.2. There is just a couple of fixes and this bind statement extension, nothing wrong can happen.

[stdweird]

then ,as usual, i misunderstood and fully agree 😄

@ned21, @jrha some MS and RAL feedback will be required what the consequences would be be to switch the test panc to 10.2. (this implies the minimal version for actual compilation if you expect to use releasd templates/schemas/... unmodified).

[jrha]

Both of our production Quattor systems use 10.2 so it is not an issue for us.

[loomis]

The panc maven plugin is available from the central maven repository. Each version of the plugin requires the same version of the pan compiler jar file indirectly through the parent pom.xml file. This version should be used in the build unless you explicitly require a different version in one of your pom.xml files.

Generally you should switch between versions of the compiler used in a maven build by switching the version of the panc-maven-plugin in the build's pom.xml files (either in a parent pom file in the pluginManagement section or a direct reference in a build/plugin section).

[jouvin]

@loomis I digged in the different pom files I was aware of but didn't find any version specifically required... Is there some sort of default version (like the last one available in the nexus repo) or is it that I missed something?

[loomis]

The version is usually specified in the pom.xml file for the configuration module. For example, you see the version in the pluginManagement section for the globuscfg configuration module here: https://github.com/quattor/configuration-modules-grid/blob/master/ncm-globuscfg/pom.xml#L51. The version is 9.0.0-RC3.

[piojo-zz]

If it's not specified in the component's POM, it is inherited from the parent POM file. We should probably use 10.2 as our new default.

[jouvin]

In fact, I looked again and I found it as said by @loomis in the component pom... I'll see if we can put it in the parent pom as I don't see a real need for a per component definition. I have the feeling that there is a good reason for it not being defined in the parent pom currently...

[jouvin]

I looked again and I am still fighting with a strange behaviour...

• I tested with repo configure-modules-core where most components but not all have panc-maven-plugin version defined to 9.0.0-RC3. Despite this version 9.3 is used when running mvn test.
• Some configuration modules don't have panc-maven-plugin referenced into their pom.xml (and there is nothing in the parent pom.xml) but they also execute panc check syntax with version 9.3.
• Upgrading the version used into the component pom.xmlworks as expected
• Moving the definition to the parent pom.xml (the one in the parent directory) does not have any effect.
• There is no reference to panc-maven-plugin in the maven build tools...

@cal or @Piojo do you have any idea where this 9.3 definition could come from?

[jouvin]

I think I made some progress... I always tend to confuse the parent pom.xml and the one in the parent directory of configuration modules... If I'm right the parent pom.xml is the one provided with the maven tools as build-profile/pom.xml.

This pom.xml does configure the panc-maven-plugin but without specifying the version. Does it mean that there is a default version defined somewhere, like in the nexus repository?

What about removing panc-maven-plugin configuration from the configuration modules (and other components) pom.xml and explicitely set the version in the parent pom.xml provided by the build tools. This would have the advantage to make clear that one version of the build tools uses one version of the pan compiler. I don't see any reason why we should not validate every part of Quattor against the same panc version as at the end they are used in configuration database where there is only one compiler version...

[piojo-zz]

I think I made some progress... I always tend to confuse the parent pom.xml and the one in the parent directory of configuration modules...

I agree it is confusing. ;)

If I'm right the parent pom.xml is the one provided with the maven tools as build-profile/pom.xml.

Yes, that's what I meant as parent pom, since yours actually inherits from this one.

This pom.xml does configure the panc-maven-plugin but without specifying the version. Does it mean that there is a default version defined somewhere, like in the nexus repository?

In that case it will always take the latest stable one. Currently 10.2. IMHO, it makes sense to depend on the latest non-snapshot compiler, but it's indeed debatable.

What about removing panc-maven-plugin configuration from the configuration modules (and other components) pom.xml

Totally! Please do!

and explicitely set the version in the parent pom.xml provided by the build tools.

I have a slight preference for letting this one version float, so that components are built with 10.3 or 11.x automatically. But it's just a small preference, if the consensus is to lock down 10.2 it's also fine by me.

[jouvin]

Except that when version is not defined, currently it takes 9.3... I have the feeling that defining the stable version is an explicit operation that has to be done in the nexus repository and that it would be easier to define this version in the pom.xml... Thus my proposal.

[loomis]

The only meta-versions defined in the nexus repository are LATEST and RELEASE pointing to the latest and latest release versions, respectively. There is no concept of a "stable" version and no way of defining that in the repository.

It is a bad idea not to define a plugin version explicitly. This makes the build depend on outside version information and may cause re-builds of previous tags to fail because different plugin versions are used compared to when the tag was made. Maven still accepts this but this may not last; such builds emit a warning that this may fail with future versions of maven. If you want to always use the latest version, use 'LATEST' or 'RELEASE' for the version; although support for this was scheduled to be removed (and may already have disappeared).

Absent an explicit version, maven should use the latest version of the plugin, but this may depend on may factors. One problem that may be causing issues is a reference to the old quattor build plugin in the maven-tools/pom.xml file. It references "maven-quattor-build-plugin," where the current name is "quattor-build-maven-plugin".

[jouvin]

@loomis thanks for this clarification. I'll try to submit a PR in the coming days with the version defined in the parent pom.xml and removed from the configuration modules pom.xml. And ensure that the reference to the old quattor build plugin is removed everywhere...

One last question that may save me some time: how to test changes in the parent pom.xml without building a release? I know how to modify the Perl modules used by hacking the target/dependency but I don't see the parent pom.xml there and there may be a better way anyway!

[jrha]

Yes please specify versions, I already get enough warnings to ignore during a release, I'd prefer less rather than more!

[loomis]

You can modify the parent reference to point to the snapshot version of the parent pom.xml file.

[jouvin]

I had a look but I didn't understand how to point to something that is not on the nexus server. Do I need to deploy a snapshot before testing or is there anyway to hack what is used and replace it by what I want to test?

[loomis]

If you run the "install" target, it should deploy the artifact to your local maven repository. It should be picked up by any builds on the same machine, although it might complain if it can't find a copy on a real server elsewhere.

[jouvin]

I tried to execute the install target but it fails because if tries to execute the rpm-maven-plugin which doesn't find the required directories... It looks a bit strange that there is an attempt to build a rpm for build-profile... What I made wrong???