How to handle branched artifacts with gradle?

Old Forum
1

We want to venture in the the world of branching.

We have many products that have dependencies on each other.

If we branch our code, we need a way to identify which artifact is from the branch(es) vs trunk. These branches would be merged back to trunk at some point inside of a full release.

What I was thinking of is having the branched code simply change the module name to reflect the branch:

trunk:
group: 'com.myco, name: 'db-tools-jdbc', version: 'latest.milestone'

"nirvana" branch:
group: 'com.myco, name: 'db-tools-jdbc=>nirvana', version: 'latest.milestone'

This way we can easily identify the artifacts as branches in the dependency lists and browsing artifactory and any consumers could opt to consume the branched artifacts if they wish by changing the module dependency name. And we still get the advantages of using snapshots and milestones.

A co-worker thinks this is a mis-use of the module name and should be handled via version numbers. I’m ok with this if we could make the version number obvious that it’s a branch. So somehow declare the version dependency like

"nirvana" branch:
group: 'com.myco, name: 'db-tools-jdbc', version: 'latest.milestone=>nirvana'

Here is a link to the ivy documentation on version strategies, but I’m not sure if we can make this work:

http://ant.apache.org/ivy/history/trunk/settings/latest-strategies.html

any thoughts are appreciated.

2

Custom Ivy ‘latest-strategies’ are not supported by Gradle.

I would agree with your co-worker: this problem would be better suited to version numbers. Why not use a version scheme like “‘branch-1.0’”? You could then use “‘branch-1.+’” in your version selector.

3

Thanks Daz,

could we distinguish between snapshots and milestone in the version? what would be the equivalent of

version: ‘latest.milestone’ for branch “nirvana”

same question for ‘latest.integration’?

I’m guessing this isn’t supported?

4

I’m guessing this isn’t supported?

That’s correct. In Ivy I suppose you could achieve this with a custom LatestStrategy together with a custom VersionMatcher. However, these things are not configurable in Gradle.

You could possibly achieve all of this using version numbers, by incorporating a pattern for your milestones. If you use 1.2-dev1 for integration, -1.2-beta1 for milestones and -1.2 for release, it may work.

This is a use-case that we don’t yet support in a nice way, however. For Maven repositories, there’s no way to differentiate between snapshots and main releases with a dynamic version like “1.+”. Any fix we introduce will need to support Maven “statuses” as well.