Overriding baseline comparators

[lppedd]

I'd like to use a customized version of BundleArtifactBaselineComparator, since we don't really follow semver semantics (e.g. new features can be delivered with a micro version change, 1.0.0 > 1.0.1).

Tried every possible combination of annotation on my custom addon, added as a dependency to the baseline plugin:

<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>tycho-baseline-plugin</artifactId>
  <version>${tychoVersion}</version>
  <dependencies>
     // My addon where a component is defined with an "eclipse-plugin" hint
  </dependencies>
</plugin>

I think one way of overriding existing beans would be to switch to use javax.* and the sisu @Priority annotation, but then the baseline mojo would have to use @Inject instead of @Component.

Any other idea?

[laeubi]

I'd like to use a customized version of BundleArtifactBaselineComparator, since we don't really follow semver semantics

Why? Baseline comparison is almost useless if you don't do so as consumers are unable to ever accommodate your changes and choose suitable version ranges.

e.g. new features can be delivered with a micro version change, 1.0.0 > 1.0.1

It doesn't matter form an API point of view how much is added as long as API stays constant (that is mostly exported packages), and in this case a micro change is really the worst one can do for your downstream consumers as it is accepted that micro changes mean API stays compatible for consumer and providers (please note that Bundle version do not need match package versions!).

Tried every possible combination of annotation on my custom addon, added as a dependency to the baseline plugin:

This is not something really supported and I'm not sure that priority will help you here (even though it should work see TychoCiFriendlyVersions for example using it) as here we use a named component and as far as I know priority does not taken into account then.

Also please note that even if you can override BundleArtifactBaselineComparator this basically means you completely replace the functionality of what tycho-basline plugin does, in such a case using an own mojo might be better anyways, but please don't claim your are doing any api baselining this will only confuse your consumers of the API if you are imposing completely different rules.

[laeubi]

Consumers are not the typical ones. Our products' versions must match components on mainframes, so we don't follow the same semantics or release processes for our release trains. Baseline checks are still useful to avoid introducing breaking API changes, but given the difference in versioning it is almost unusable.

Component versions must not match Bundle Version what must not match exported package versions. You can for example disable the version check for bundle and then only version the packages properly. But the version compare itself wont work if do not follow semantic versioning.

The idea of replacing a single component is to not have to re-implement the entirety of the plugin, but only that single piece of code.

The "single component" is the baseline check, the (outer) mojo is just deciding on the type who is responsible to do the actual work, if you replace that component and want completely different semantics then the mojo will not help you much I fear.

I have a bunch of mojos using @Inject, and testing @priority it looks like it works as expected.
When I switch back to @component, priorities stop working.

If you like you can upgrade the Mojo to JSR330 I made some basic attempts here:

• Move components to JSR330 #3325

but its not really high on the priority list, so if you want to work on it it would be welcome.

[lppedd]

Ah nice that you're switching to JSR 330.

Will that target Tycho 5.* or also Tycho 4.*?
I can definitely have a look at updating the mojo and opening a PR.

[laeubi]

It depends, if we can apply it without major refactoring it can be backported to Tycho 4.

[lppedd]

Incredibly I can inject my own comparator, but I cannot get the two default comparators to be injected.

<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>tycho-baseline-plugin</artifactId>
  <version>${tychoVersion}</version>
  <extensions>true</extensions>
  <dependencies>
    <dependency>
      <groupId>com.hcl.mainframe.maven.addons</groupId>
      <artifactId>baseline-tycho</artifactId>
      <version>1.0.0-SNAPSHOT</version>
    </dependency>
  </dependencies>
  ...
</plugin>

[laeubi]

@lppedd I assume they must then be JSR330 componetns as well... but thats just guessing, as I always find big constructors hard to understand/maintain, maybe you can try field injection as well, maybe it makes even a difference not sure.