Jean-Michel Fayard

@toddobryan we are not going to do this sorry An alternative is to do something like this: ``` dependencies { implementation("com.group:my-lib:" + versionFor("version.xxx")) } ``` See https://jmfayard.github.io/refreshVersions/add-dependencies/#get-the-version-from-anywhere

@alandoni I tried to reproduce the problem and ideed got an issue. Can you confirm that it was was you were experiencing? See https://github.com/jmfayard/refreshVersions/commit/74697b49c8a0c7c51921fdbb91c2dd30dad92352

I don't think this use case is important right now. If lots of people were asking to create their own plugins on top of refreshVersions-dependencies we should do that. I...

@mgray88 please describe your use case separately if you think it's important

@sschuberth given limited time and energy, we try to optimize refreshVersions for people who use it, not for people who don't really use it. I'm closing this as won't fix.

How would that help most people using refreshVersions? Adding tons of options and features few people use does not make a software better. It make it harder to use and...

Too many configuration options is a minus, not a plus. We can start by documenting what we already have.

see https://github.com/jmfayard/refreshVersions/wiki/Draft:-configuration-options

@brewin developers are crazy creative with their naming scheme The simplest solution is to use a `rejectVersionIf` https://jmfayard.github.io/refreshVersions/update-dependencies/#filter-which-versions-are-added-to-versionsproperties

@imashnake0 wow thanks for the report. Anyone is welcome to work on this Just curious, did you do that manually? Seems like lots of tedious work.