[wildfly-dev] Automate keeping Wildfly dependencies up-to-date?

[Tomas Hofman]

Hi Fernando,

I have a little issue with Maven ranges regarding how it handles qualifier part 
of the version.

E.g. range "[1.2.3-1.3)" would also accept "1.2.4-Beta1", which may not be 
desirable.

I don't know Gemfiles version specs well, but I expect it would behave similarly?

I could add it as another option if it helps somebody. It would probably work 
for many (most?) cases, but I would like to have something more expressive 
available too.

I'm not at all sure yet what is the best way to express these rules. Another 
aspect of this is how much maintenance will this configuration require. For 
instance when I use Maven version range "[1.2,1.3)" (or "PREFIX: 1.2" in 
current notation), sooner or later we switch this dependency to 1.3 minor, and 
someone would have to go and update the configured range to "[1.3,1.4)" (or 
"PREFIX: 1.3"). On the other hand if I just say "USE LATEST MICRO", then I need 
to update the configuration much less often, because it will just keep working.

Thanks for suggestion!

Tomas

On 03/09/2019 16:09, Fernando Nasser wrote:
> Nice idea.  Thomas, have you tried adopting an already established
> format for the allowed versions?  Either Maven ranges or the Gemfiles
> (Ruby) version specs?
> 
> Fernando
> 
> 
> On 2019-09-02 3:44 a.m., Tomas Hofman wrote:
>> Hello,
>>
>> would the Wildfly team be interested in (or opposed to) receiving component
>> upgrade PRs, which would be created automatically when a new component version
>> is released? (I'm talking about new micro/SP versions, depending on the
>> component, i.e. version that could be reasonably expected to be suitable for
>> consumption, without issues like breaking API changes etc.)
>>
>> I'm working on a tool [1], which is able to provide these PRs.
>>
>> The tool scans given project for dependencies, and then looks at what versions
>> of those dependencies are available in Maven Central and possibly other
>> repositories. I can configure rules for each dependency, that specify what
>> versions should be considered viable for upgrading (e.g. for "org.picketlink:*"
>> we would only offer new "SP" builds in the same micro, for most of the other
>> dependencies we would only offer new micros, and some artifacts would perhaps
>> be blacklisted). Example of this configuration is here [2].
>>
>> Advantages that I believe could be gained from this:
>>
>> * It would bring us an advantage of having new component micros tested soon in
>> Wildfly, and therefore having more confidence when we need to do the same
>> upgrades in EAP.
>>
>> * It would also help in preventing EAP running ahead of Wildfly in component
>> versions, which happens occasionally. EAP release coordinator usually spots
>> this problem and creates missing PR in Wildfly, but it's a manual check and
>> therefore a small risk remains.
>>
>> * It would ensure Wildfly is consuming latest component fixes.
>>
>> You can review PRs generated last week in my fork of Wildfly [3].
>>
>> It's a work in progress, I expect the tool and it's configuration would evolve
>> according to experiences we would get from using it...
>>
>> What do you think?
>>
>> [1] https://github.com/TomasHofman/maven-dependency-updater/
>> [2]
>> https://github.com/jboss-set/dependency-alignment-configs/blob/master/wildfly-18-minimal.json#L44
>> [3] https://github.com/TomasHofman/wildfly/pulls
>>
> 

-- 
Tomas Hofman
Software Engineer, JBoss SET
Red Hat