Release multiple projeccts from same git repo

Hi,

I’m currently using the old plugin, gradle-git, but considering the switch to this one. I am wondering if reckon can handle multi project releases from the same git repo?

Our use case is as follows:

We have some gradle modules that use GRPC and we generate code from the proto files. Let’s call this project report-generator We have the proto files in the git repository where we have the server module of our report-generator. We implement the grpc client of this report-generator service in other projects that live in other git repositories.

We use gradle git for releasing the server module of report-generator and this creates a different version of our GRPC API artifact.

We would like to be able to release our grpc module from report-generor service only when there are changes to it and not every time.

Moving this code into another git repo will make things harder to track and manage (submodules is an option but adds it’s own issues).

Is there a way to have our report-generator grpc api as an independent project inside the report-generaor git repository and handle releases via separate tags?

Something like:

• v-x.y.z tag format to manage release numbering for the main project report-generator
• reports-api-a.b.c tag format to manage release numbering for report-generator grpc api

What other options do I have if that is not possible?

Thanks,

On release we publish our artifacts to Sonatype nexus and we are

[ieugen]

I’m coming back to this with more info and insight. I believe more and more that it is a usefull thing to have since I have noticed projects that need this functionality in practice.

I’m swamped with work and can’t tackle this but hopefully that time will come or someone else wil beat me to it. In the mean time this can serve as use case documentation.

1. Apache Sling - releases OSGi bundles and uses Maven as a build. Since each bundle has it’s own version, they provide 1 git repo / module (bundle). Now when developing you usually need to change code in multiple projects. The solution they use is to use git-repo [1] to automate downloading all of the git repositories locally [2] .

This works but needs another tool to work with. Having multi version support in same git repo will eliminate this need.

1. Lerna . This is a tool from Javascript world that allows you to publish multiple npm packages from same git repo. Now, I believe that npm format and publishing is more limitted than maven ( no support for classifiers, extensions -> you can publish only 1 artifact / package). So they found this approach (bit is another [4] ) to make it so they can publish multiple packages from same git repo.

Of course both approaches use hard-coded versions inside scripts.

[1] https://gerrit.googlesource.com/git-repo/ [2] https://github.com/apache/sling-aggregator [3] https://lernajs.io/ [4] https://github.com/teambit/bit

[lwasyl]

Another challenge is that the plugin (right now) applies to the root project only and the version is used across all projects in the build. This is the core use case, so I wouldn’t want the version to recalculate for each project when they’re going to have the same result.

What’s the reason to apply the plugin only to the root project? It seems like it’s an artificial limitation created due to the fact that in current state it doesn’t make sense to have the plugin applied to child projects for the reasons you mentioned, but it wouldn’t inherently break the build or the plugin. Thus this limitation could be lifted, if only there was some strategy for the plugin to determine version for the specific project in which it’s applied.

Seems to me like e.g. prefixing the tags with fixed project prefix would allow the plugin to use only relevant subset of git tags to determine versions, without more changes. Unless, of course, there’s something I’m missing.

The you can only apply reckon to the root project limitation can still be present if e.g. there are no project-specific tag prefixes specified. And everything would be backwards compatible.