Hello Juhan,

Sorry for the late reply to this email.

Your contributions and ideas are valuable and you're encouraged to keep
thinking of ways to better the Fineract CN project.

I see that you've done quite some research and experimenting with jitpack.io
and I think it can be a great tool for our CI/CD pipeline.

However, just like you, I have some concerns;

1. Is it absolutely necessary that artifact names need to be changed from
org.apache.fineract.cn to com.github. This can turn out quite ugly because
even though the project is open source, it is owned by the Apache Software
Fondation...NOT Github. If org.apache works, then would we have to change
the artifact names to org.apache.fineract-cn-provisioner for example ?
com.github.apache would sound like Github owns the project and that's
obviously NOT the case.

2. Are changes really needed to the naming convention of the artifact
versions such as 0.1.0-BUILD-SNAPSHOT to develop-SNAPSHOT ?

I wish that your interests/passion in working on continuous
integration/delivery for Fineract CN comes to full fruition. Do you think
there are any alternative more flexible CI/CD tools which we can use for
the project ? How much would you need from Apache Fineract to use the paid
versions of these tools ( Travis, JFrog ) for a specific period of time ?
Perhaps a clear budget documented on Confluence could help throw more light
to the PMC on exactly the resources to lobby to achieve this.

More grease to your elbows. You're doing great !

Cheers,
Isaac Kamga.

On Thu, Mar 21, 2019 at 3:53 PM 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
>

Reply via email to