Hi Juhan, Thanks for taking this on!
I would agree that 2 (changing the artifact name) and 3 aren't major concerns. Changing the group name, however, is less than ideal as both you and Isaac have pointed out. If you are considering alternatives, we do have an open-source license for https://jfrog.com/artifactory/ . Regards, Vishwas On Thu, Mar 21, 2019 at 7:53 AM Juhan Aasaru <[email protected]> wrote: > Hi community! > > I created a proof-of-concept how we could use jitpack.io for fineract-cn > projects. With this email I would start a discussion if and how we could > get these changes done. I hope you have some time to go through my rather > long email and maybe even look at the proof-of-concept that I put together > (references in the end of email) and join the discussion. > > My opinion is that although some changes are needed I feel that the > benefits are worth some of the inconveniences that come with some of the > renamings. > > So let's start from the beginning. I was looking into jitpack.io for two > reasons: > > 1) to add travis-ci to fineract-cn projects we need a mechanism to keep and > serve all the dependencies to other fineract-cn projects. > 2) to publish public docker images for fineract-cn projects then we need > some service (that is not someones personal computer) to build the jar-s > first. > > If you are not familiar with fineract-cn then I can give you a quick > example of the problem: > In order to build fineract-cn-portfolio you need (among other things) > fineract-cn-rhythm built first. > In order to build fineract-cn-rhythm you need fineract-cn-identity. > In order to build fineract-cn-identity you need fineract-cn-anubis. > In order to build fineract-cn-anubis you need fineract-cn-api > In order to build fineract-cn-api you need fineract-cn-lang. > > So jitpack.io should be just the service what is needed for this. While in > maven central you have to publish each version then jitpack just clones the > code from a public repo, builds it and if the build is successful starts to > serve it. You can refer to both latest successful build of a branch, to a > tagged version or use commit hash instead of a version number. So the > service is very flexible. > > My goal was to find out what changes (if any) would be needed to adapt. And > also build a proof-of-concept (not to stay only theoretical). > > 1. The first problem was that fineract-ch projects are hosted in github but > fineract-cn uses a domain name (org.apache.fineract.cn) instead of > com.github.username. Jitpack supports custom domain names but after some > tests and contacting with them ( > https://github.com/jitpack/jitpack.io/issues/3781) it came clear that they > don't (yet) support subdomains (so org.apache would work but not > org.apache.fineract.cn). > > To overcome the first issue fineract-cn projects should change group names > of artifacts from org.apache.fineract.cn to com.github.apache (until > jitpack.io starts to support subdomains). For official releases in Maven > Central it would be possible still to use org.apache.fineract.cn group > names. Of course, it would be inconvenient but in my opinion it would be > doable. > > 2. The second problem of using jitpack.io is that the repository name is > built deeply into its logic. If you have a public repository: > https://github.com/username/repository-name > then "repository-name" has to appear either in the group name or in the > artifact name. > > So for fineract-cn projects it would mean changes. Currently simpler > projects (lang, async, api, test) you require like this: > > [group: 'org.apache.fineract.cn', name: 'lang', version: > versions.frameworklang], > to use jitpack.io these would change to: > [group: 'com.github.apache', name: 'fineract-cn-lang', version: > versions.frameworklang], > > And the main projects (that have sub-projects) that are currently required > like this: > > [group: 'org.apache.fineract.cn.identity', name: 'api'], > would change to: > [group: 'com.github.apache.fineract-cn-identity', name: 'api', version: > rootProject.version], > (and in released versions and once jitpack would start to support > subdomains it would change to: > [group: 'org.apache.fineract.cn.fineract-cn-identity', name: 'api'], > > 3. A third change is also needed. Jitpack has snapshots in a form of: > branchname-SNAPSHOT > since fineract-cn projects are all in develop branch it would mean changing > to > 0.1.0-BUILD-SNAPSHOT -> develop-SNAPSHOT > In my opinion this shouldn't be a problem - this is just matter of whatever > we agree to use. > > > So I created a (rather-huge) proof-of-concept to get this list of changes. > I created a separate github user "mobjex" and forked all fineract-cn > projects. > Then I added jitpack.io to list of repositories and started making changes > that I described above. Since I crated a separate github user I had to use > "mobjex" anywhere instead of "apache". But this is just proof-of-concept > and once we agree on the idea this will be all replaced back to "apache". > > My goal was to get jitpack to build an serve identity project (I chose a > subset of all the projects): > > As you can see from the banner I managed to build it with jitpack: > https://github.com/mobjex/fineract-cn-identity/ > you can see the changes I had to make here: > > https://github.com/apache/fineract-cn-identity/compare/develop...mobjex:develop > > also, I had to make changes to all the projects that identity depends on so > I changed: > > > https://github.com/apache/fineract-cn-anubis/compare/develop...mobjex:develop > https://github.com/apache/fineract-cn-api/compare/develop...mobjex:develop > https://github.com/apache/fineract-cn-lang/compare/develop...mobjex:develop > https://github.com/apache/fineract-cn-test/compare/develop...mobjex:develop > > https://github.com/apache/fineract-cn-async/compare/develop...mobjex:develop > https://github.com/apache/fineract-cn-lang/compare/develop...mobjex:develop > and maybe a few others. > > I'm looking forward to your feedback and questions. > > Kind regards > Juhan Aasaru >
