You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Juhan Aasaru <aa...@gmail.com> on 2019/03/21 14:52:17 UTC
Building and serving fineract-cn artifacts with jitpack.io
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
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Juhan Aasaru <aa...@gmail.com>.
Hi Ebenezer,
I understand now what you want to do.
One way to see the failed rat report would be instructing travis (in
.travis.yml) to output contents of rat report to its logs like this:
after_failure:
- cat build/reports/rat/index.html
If you think this adds value then you can test it out and create pull
requests.
Regarding notifications.
It seems I have somehow missed to create pull request with travis code for
fineract-cn-notifications repo.
I had all the code ready on my fork so the pull request is now out there
waiting for review.
Also travis.yml contains encrypted artifactory password that has to be
encrypted with public key created by travis for the specific repository.
Encrypted password cannot be copy-pasted from any other repository. So code
from your PR would fail in upload to artifactory after PR merge.
Kind regards
Juhan
Juhan
Kontakt Ebenezer Graham (<eg...@alustudent.com>) kirjutas kuupäeval R,
24. mai 2019 kell 09:49:
> Hi Juhan,
>
> It's easy to see a compilation error however the experience which led to
> this suggestion was actually a rat report eg:
> https://travis-ci.com/apache/fineract-cn-notifications/builds/111233630
>
> I got a weird issue where all rat checks passed on my local dev but failed
> on the Pull Request
>
> https://github.com/apache/fineract-cn-notifications/pull/9#issuecomment-490977282
>
> I later had to simulate it on my personal Travis to export the HTML report
>
> This is why I suggested this. But on second thoughts, if compilation
> errors are well displayed then we can trade off the rat report or find a
> way to display that as well if it becomes a common issue.
>
> *At your service,*
>
> *Ebenezer Graham*
>
>
>
>
> On Fri, 24 May 2019 at 09:35, Juhan Aasaru <aa...@gmail.com> wrote:
>
>> Hi Ebenezer,
>>
>> thanks for the good feedback and proposing enhancements.
>>
>> If you use pull requests then (normally) only your own build can fail,
>> you shouldn't be able to merge any pull request that fails.
>> So the information that build failed is relevant only for the authors of
>> the pull request not all the developers of Fineract.
>> Develop branch should normally never fail (as long as anyone doesn't
>> bypass submitting the pull request).
>>
>> Regarding the logs - you can get the build logs directly from travis via
>> web.
>> For example - there is a failing pull request here at the moment:
>> https://github.com/apache/fineract-cn-demo-server/pull/27
>> If you expand Travis and then click
>> The build
>> <https://travis-ci.com/apache/fineract-cn-demo-server/builds/111226324>
>> failed
>> then you get the full console output of the failing build.
>>
>> I hope I understood your poroblem right but feel free to elaborate.
>>
>> Kind regards
>> Juhan
>>
>>
>>
>> Kontakt Ebenezer Graham (<eg...@alustudent.com>) kirjutas kuupäeval
>> N, 23. mai 2019 kell 23:41:
>>
>>> Hi Community / Juhan,
>>>
>>> Nice job with the Travis CI integration. They are working nicely! In
>>> addition, I want to suggest an idea.
>>>
>>> Can we have an after failure procedure in the .travis.yml to make the
>>> log output of a failed build available to Fineract developers?
>>>
>>> As you may already know, with TravisCI, there is no way to login/ssh
>>> into a build machine to inspect the job's log output interactively. And
>>> so for instance, zipping and publishing rat reports, component-test and
>>> service build logs for analysis will come in handy for a number of
>>> developers as we venture into CI/CD.
>>>
>>> I believe the common approach is by defining an after_failure script to
>>> dump the logs in to log aggregator of our choosing. The major problem here
>>> will be "where to publish the logs"
>>>
>>> Also, I will create an issue on Jira to keep track of this suggestion.
>>>
>>> Looking forward to your response.
>>>
>>>
>>> *At your service,*
>>>
>>> *Ebenezer Graham*
>>>
>>>
>>>
>>>
>>> On Thu, 25 Apr 2019 at 15:43, Juhan Aasaru <aa...@gmail.com> wrote:
>>>
>>>> Hey,
>>>>
>>>> thank you for feedback and help Vishwas and Courage.
>>>> I have now created 30 pull requests for getting travis to build and
>>>> upload to artifactory, all linked here ander Issue links:
>>>> https://issues.apache.org/jira/browse/FINCN-148
>>>> Its mostly copy-and-paste. Travis now builds all pull requests
>>>> including the requests created by me.
>>>>
>>>> For identity I also changed the Dockerfile to wget the artifact from
>>>> Artifcatory.
>>>> I didn't add this to any other project yet (I plan to keep it a
>>>> separate task).
>>>>
>>>> I hope some reviewer has a chance to go over my pull requests.
>>>>
>>>> Kind regards
>>>> Juhan
>>>>
>>>>
>>>>
>>>> Kontakt Courage Angeh (<co...@gmail.com>) kirjutas kuupäeval R,
>>>> 12. aprill 2019 kell 02:27:
>>>>
>>>>> Hi Juhan,
>>>>>
>>>>> Nice work!. The code base and documentation looks good.
>>>>>
>>>>> Regards,
>>>>> Courage.
>>>>>
>>>>> On Thu, Apr 11, 2019 at 7:16 PM Vishwas Babu <
>>>>> vishwas@confluxtechnologies.com> wrote:
>>>>>
>>>>> > +1
>>>>> > Looks good to me
>>>>> >
>>>>> >
>>>>> > Regards,
>>>>> > Vishwas
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, Apr 11, 2019 at 9:13 AM Juhan Aasaru <aa...@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > > Hi!
>>>>> > >
>>>>> > > I have proof-of-concept ready and I have managed to build and
>>>>> publish
>>>>> > > fineract-cn-identity artifacts with Travis.
>>>>> > > All the fineract-cn-* projects that idenity depends on I made
>>>>> forks and
>>>>> > set
>>>>> > > Travis to build and publish those artifacts.
>>>>> > > Before I go over rest of the projects and create pull requests
>>>>> please
>>>>> > have
>>>>> > > a look and comment if you have time
>>>>> > > (I think most important is to agree on artifact naming for
>>>>> non-develop
>>>>> > > brannches and review changes to *.gradle files)
>>>>> > >
>>>>> > > The idea is that Travis builds snapshot artifacts and uploads them
>>>>> to
>>>>> > > https://mifos.jfrog.io/mifos/libs-snapshot/org/apache/fineract/cn/
>>>>> > > (I created user "travis-ci" to artifactory with upload permissions
>>>>> and
>>>>> > > encrypted its password for each repository)
>>>>> > > Travis detects branch automatically and if branch=develop (in my
>>>>> code
>>>>> > > currently i have set branch=travis) then it uses version set in
>>>>> > > build.gradle
>>>>> > > For any other branch it sets artifact version to
>>>>> branchname-SNAPSHOT
>>>>> > > If one creates a release in github then it uses tag as version and
>>>>> > uploads
>>>>> > > it under different repoKey,
>>>>> > > so that it will be available here:
>>>>> > > https://mifos.jfrog.io/mifos/libs-release/org/apache/fineract/cn/
>>>>> > > Travis will also build all pull requests but those artifacts are
>>>>> not
>>>>> > > uploaded anywhere.
>>>>> > >
>>>>> > > I have documented the usage and setup here:
>>>>> > >
>>>>> > >
>>>>> >
>>>>> https://cwiki.apache.org/confluence/display/FINERACT/Fineract-CN+Artifactory
>>>>> > >
>>>>> > > Here is travis build log for Idenity project:
>>>>> > > https://travis-ci.com/aasaru/fineract-cn-identity
>>>>> > >
>>>>> > > And the code changes of fineract-cn-idenity:
>>>>> > >
>>>>> > >
>>>>> >
>>>>> https://github.com/apache/fineract-cn-identity/compare/develop...aasaru:travis
>>>>> > > All the other repos github.com/aasaru/fineract-cn-* will have
>>>>> similar
>>>>> > > changes
>>>>> > > (travis.sh will be identical everywhere and .travis.yml as well
>>>>> (except
>>>>> > the
>>>>> > > encrypted password)
>>>>> > >
>>>>> > > Please let me know if you have any comments or if you have none
>>>>> then I
>>>>> > will
>>>>> > > create pull requests next week.
>>>>> > >
>>>>> > > Kind regards
>>>>> > > Juhan
>>>>> > >
>>>>> > >
>>>>> > > Kontakt Isaac Kamga (<is...@mifos.org>) kirjutas kuupäeval
>>>>> P, 31.
>>>>> > > märts 2019 kell 18:59:
>>>>> > >
>>>>> > > > Hello Juhan,
>>>>> > > >
>>>>> > > > Yes, get started with the proof of concept. You'll also need to
>>>>> create
>>>>> > > > issues for the CI/CD work you're doing and probably name
>>>>> branches after
>>>>> > > the
>>>>> > > > issue number.
>>>>> > > >
>>>>> > > > Vishwas mentioned that a Jfrog open source license is available
>>>>> for
>>>>> > > Apache
>>>>> > > > Fineract. I think he's best placed to get those details though
>>>>> to you.
>>>>> > > >
>>>>> > > > More grease to your elbows.
>>>>> > > >
>>>>> > > > Cheers,
>>>>> > > > Isaac Kamga.
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Ebenezer Graham <eg...@alustudent.com>.
Hi Juhan,
It's easy to see a compilation error however the experience which led to
this suggestion was actually a rat report eg:
https://travis-ci.com/apache/fineract-cn-notifications/builds/111233630
I got a weird issue where all rat checks passed on my local dev but failed
on the Pull Request
https://github.com/apache/fineract-cn-notifications/pull/9#issuecomment-490977282
I later had to simulate it on my personal Travis to export the HTML report
This is why I suggested this. But on second thoughts, if compilation errors
are well displayed then we can trade off the rat report or find a way to
display that as well if it becomes a common issue.
*At your service,*
*Ebenezer Graham*
On Fri, 24 May 2019 at 09:35, Juhan Aasaru <aa...@gmail.com> wrote:
> Hi Ebenezer,
>
> thanks for the good feedback and proposing enhancements.
>
> If you use pull requests then (normally) only your own build can fail, you
> shouldn't be able to merge any pull request that fails.
> So the information that build failed is relevant only for the authors of
> the pull request not all the developers of Fineract.
> Develop branch should normally never fail (as long as anyone doesn't
> bypass submitting the pull request).
>
> Regarding the logs - you can get the build logs directly from travis via
> web.
> For example - there is a failing pull request here at the moment:
> https://github.com/apache/fineract-cn-demo-server/pull/27
> If you expand Travis and then click
> The build
> <https://travis-ci.com/apache/fineract-cn-demo-server/builds/111226324>
> failed
> then you get the full console output of the failing build.
>
> I hope I understood your poroblem right but feel free to elaborate.
>
> Kind regards
> Juhan
>
>
>
> Kontakt Ebenezer Graham (<eg...@alustudent.com>) kirjutas kuupäeval
> N, 23. mai 2019 kell 23:41:
>
>> Hi Community / Juhan,
>>
>> Nice job with the Travis CI integration. They are working nicely! In
>> addition, I want to suggest an idea.
>>
>> Can we have an after failure procedure in the .travis.yml to make the log
>> output of a failed build available to Fineract developers?
>>
>> As you may already know, with TravisCI, there is no way to login/ssh into
>> a build machine to inspect the job's log output interactively. And so
>> for instance, zipping and publishing rat reports, component-test and
>> service build logs for analysis will come in handy for a number of
>> developers as we venture into CI/CD.
>>
>> I believe the common approach is by defining an after_failure script to
>> dump the logs in to log aggregator of our choosing. The major problem here
>> will be "where to publish the logs"
>>
>> Also, I will create an issue on Jira to keep track of this suggestion.
>>
>> Looking forward to your response.
>>
>>
>> *At your service,*
>>
>> *Ebenezer Graham*
>>
>>
>>
>>
>> On Thu, 25 Apr 2019 at 15:43, Juhan Aasaru <aa...@gmail.com> wrote:
>>
>>> Hey,
>>>
>>> thank you for feedback and help Vishwas and Courage.
>>> I have now created 30 pull requests for getting travis to build and
>>> upload to artifactory, all linked here ander Issue links:
>>> https://issues.apache.org/jira/browse/FINCN-148
>>> Its mostly copy-and-paste. Travis now builds all pull requests including
>>> the requests created by me.
>>>
>>> For identity I also changed the Dockerfile to wget the artifact from
>>> Artifcatory.
>>> I didn't add this to any other project yet (I plan to keep it a separate
>>> task).
>>>
>>> I hope some reviewer has a chance to go over my pull requests.
>>>
>>> Kind regards
>>> Juhan
>>>
>>>
>>>
>>> Kontakt Courage Angeh (<co...@gmail.com>) kirjutas kuupäeval R,
>>> 12. aprill 2019 kell 02:27:
>>>
>>>> Hi Juhan,
>>>>
>>>> Nice work!. The code base and documentation looks good.
>>>>
>>>> Regards,
>>>> Courage.
>>>>
>>>> On Thu, Apr 11, 2019 at 7:16 PM Vishwas Babu <
>>>> vishwas@confluxtechnologies.com> wrote:
>>>>
>>>> > +1
>>>> > Looks good to me
>>>> >
>>>> >
>>>> > Regards,
>>>> > Vishwas
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Apr 11, 2019 at 9:13 AM Juhan Aasaru <aa...@gmail.com>
>>>> wrote:
>>>> >
>>>> > > Hi!
>>>> > >
>>>> > > I have proof-of-concept ready and I have managed to build and
>>>> publish
>>>> > > fineract-cn-identity artifacts with Travis.
>>>> > > All the fineract-cn-* projects that idenity depends on I made forks
>>>> and
>>>> > set
>>>> > > Travis to build and publish those artifacts.
>>>> > > Before I go over rest of the projects and create pull requests
>>>> please
>>>> > have
>>>> > > a look and comment if you have time
>>>> > > (I think most important is to agree on artifact naming for
>>>> non-develop
>>>> > > brannches and review changes to *.gradle files)
>>>> > >
>>>> > > The idea is that Travis builds snapshot artifacts and uploads them
>>>> to
>>>> > > https://mifos.jfrog.io/mifos/libs-snapshot/org/apache/fineract/cn/
>>>> > > (I created user "travis-ci" to artifactory with upload permissions
>>>> and
>>>> > > encrypted its password for each repository)
>>>> > > Travis detects branch automatically and if branch=develop (in my
>>>> code
>>>> > > currently i have set branch=travis) then it uses version set in
>>>> > > build.gradle
>>>> > > For any other branch it sets artifact version to branchname-SNAPSHOT
>>>> > > If one creates a release in github then it uses tag as version and
>>>> > uploads
>>>> > > it under different repoKey,
>>>> > > so that it will be available here:
>>>> > > https://mifos.jfrog.io/mifos/libs-release/org/apache/fineract/cn/
>>>> > > Travis will also build all pull requests but those artifacts are not
>>>> > > uploaded anywhere.
>>>> > >
>>>> > > I have documented the usage and setup here:
>>>> > >
>>>> > >
>>>> >
>>>> https://cwiki.apache.org/confluence/display/FINERACT/Fineract-CN+Artifactory
>>>> > >
>>>> > > Here is travis build log for Idenity project:
>>>> > > https://travis-ci.com/aasaru/fineract-cn-identity
>>>> > >
>>>> > > And the code changes of fineract-cn-idenity:
>>>> > >
>>>> > >
>>>> >
>>>> https://github.com/apache/fineract-cn-identity/compare/develop...aasaru:travis
>>>> > > All the other repos github.com/aasaru/fineract-cn-* will have
>>>> similar
>>>> > > changes
>>>> > > (travis.sh will be identical everywhere and .travis.yml as well
>>>> (except
>>>> > the
>>>> > > encrypted password)
>>>> > >
>>>> > > Please let me know if you have any comments or if you have none
>>>> then I
>>>> > will
>>>> > > create pull requests next week.
>>>> > >
>>>> > > Kind regards
>>>> > > Juhan
>>>> > >
>>>> > >
>>>> > > Kontakt Isaac Kamga (<is...@mifos.org>) kirjutas kuupäeval
>>>> P, 31.
>>>> > > märts 2019 kell 18:59:
>>>> > >
>>>> > > > Hello Juhan,
>>>> > > >
>>>> > > > Yes, get started with the proof of concept. You'll also need to
>>>> create
>>>> > > > issues for the CI/CD work you're doing and probably name branches
>>>> after
>>>> > > the
>>>> > > > issue number.
>>>> > > >
>>>> > > > Vishwas mentioned that a Jfrog open source license is available
>>>> for
>>>> > > Apache
>>>> > > > Fineract. I think he's best placed to get those details though to
>>>> you.
>>>> > > >
>>>> > > > More grease to your elbows.
>>>> > > >
>>>> > > > Cheers,
>>>> > > > Isaac Kamga.
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Juhan Aasaru <aa...@gmail.com>.
Hi Ebenezer,
thanks for the good feedback and proposing enhancements.
If you use pull requests then (normally) only your own build can fail, you
shouldn't be able to merge any pull request that fails.
So the information that build failed is relevant only for the authors of
the pull request not all the developers of Fineract.
Develop branch should normally never fail (as long as anyone doesn't bypass
submitting the pull request).
Regarding the logs - you can get the build logs directly from travis via
web.
For example - there is a failing pull request here at the moment:
https://github.com/apache/fineract-cn-demo-server/pull/27
If you expand Travis and then click
The build
<https://travis-ci.com/apache/fineract-cn-demo-server/builds/111226324>
failed
then you get the full console output of the failing build.
I hope I understood your poroblem right but feel free to elaborate.
Kind regards
Juhan
Kontakt Ebenezer Graham (<eg...@alustudent.com>) kirjutas kuupäeval N,
23. mai 2019 kell 23:41:
> Hi Community / Juhan,
>
> Nice job with the Travis CI integration. They are working nicely! In
> addition, I want to suggest an idea.
>
> Can we have an after failure procedure in the .travis.yml to make the log
> output of a failed build available to Fineract developers?
>
> As you may already know, with TravisCI, there is no way to login/ssh into
> a build machine to inspect the job's log output interactively. And so for
> instance, zipping and publishing rat reports, component-test and service
> build logs for analysis will come in handy for a number of developers as we
> venture into CI/CD.
>
> I believe the common approach is by defining an after_failure script to
> dump the logs in to log aggregator of our choosing. The major problem here
> will be "where to publish the logs"
>
> Also, I will create an issue on Jira to keep track of this suggestion.
>
> Looking forward to your response.
>
>
> *At your service,*
>
> *Ebenezer Graham*
>
>
>
>
> On Thu, 25 Apr 2019 at 15:43, Juhan Aasaru <aa...@gmail.com> wrote:
>
>> Hey,
>>
>> thank you for feedback and help Vishwas and Courage.
>> I have now created 30 pull requests for getting travis to build and
>> upload to artifactory, all linked here ander Issue links:
>> https://issues.apache.org/jira/browse/FINCN-148
>> Its mostly copy-and-paste. Travis now builds all pull requests including
>> the requests created by me.
>>
>> For identity I also changed the Dockerfile to wget the artifact from
>> Artifcatory.
>> I didn't add this to any other project yet (I plan to keep it a separate
>> task).
>>
>> I hope some reviewer has a chance to go over my pull requests.
>>
>> Kind regards
>> Juhan
>>
>>
>>
>> Kontakt Courage Angeh (<co...@gmail.com>) kirjutas kuupäeval R,
>> 12. aprill 2019 kell 02:27:
>>
>>> Hi Juhan,
>>>
>>> Nice work!. The code base and documentation looks good.
>>>
>>> Regards,
>>> Courage.
>>>
>>> On Thu, Apr 11, 2019 at 7:16 PM Vishwas Babu <
>>> vishwas@confluxtechnologies.com> wrote:
>>>
>>> > +1
>>> > Looks good to me
>>> >
>>> >
>>> > Regards,
>>> > Vishwas
>>> >
>>> >
>>> >
>>> > On Thu, Apr 11, 2019 at 9:13 AM Juhan Aasaru <aa...@gmail.com> wrote:
>>> >
>>> > > Hi!
>>> > >
>>> > > I have proof-of-concept ready and I have managed to build and publish
>>> > > fineract-cn-identity artifacts with Travis.
>>> > > All the fineract-cn-* projects that idenity depends on I made forks
>>> and
>>> > set
>>> > > Travis to build and publish those artifacts.
>>> > > Before I go over rest of the projects and create pull requests please
>>> > have
>>> > > a look and comment if you have time
>>> > > (I think most important is to agree on artifact naming for
>>> non-develop
>>> > > brannches and review changes to *.gradle files)
>>> > >
>>> > > The idea is that Travis builds snapshot artifacts and uploads them to
>>> > > https://mifos.jfrog.io/mifos/libs-snapshot/org/apache/fineract/cn/
>>> > > (I created user "travis-ci" to artifactory with upload permissions
>>> and
>>> > > encrypted its password for each repository)
>>> > > Travis detects branch automatically and if branch=develop (in my code
>>> > > currently i have set branch=travis) then it uses version set in
>>> > > build.gradle
>>> > > For any other branch it sets artifact version to branchname-SNAPSHOT
>>> > > If one creates a release in github then it uses tag as version and
>>> > uploads
>>> > > it under different repoKey,
>>> > > so that it will be available here:
>>> > > https://mifos.jfrog.io/mifos/libs-release/org/apache/fineract/cn/
>>> > > Travis will also build all pull requests but those artifacts are not
>>> > > uploaded anywhere.
>>> > >
>>> > > I have documented the usage and setup here:
>>> > >
>>> > >
>>> >
>>> https://cwiki.apache.org/confluence/display/FINERACT/Fineract-CN+Artifactory
>>> > >
>>> > > Here is travis build log for Idenity project:
>>> > > https://travis-ci.com/aasaru/fineract-cn-identity
>>> > >
>>> > > And the code changes of fineract-cn-idenity:
>>> > >
>>> > >
>>> >
>>> https://github.com/apache/fineract-cn-identity/compare/develop...aasaru:travis
>>> > > All the other repos github.com/aasaru/fineract-cn-* will have
>>> similar
>>> > > changes
>>> > > (travis.sh will be identical everywhere and .travis.yml as well
>>> (except
>>> > the
>>> > > encrypted password)
>>> > >
>>> > > Please let me know if you have any comments or if you have none then
>>> I
>>> > will
>>> > > create pull requests next week.
>>> > >
>>> > > Kind regards
>>> > > Juhan
>>> > >
>>> > >
>>> > > Kontakt Isaac Kamga (<is...@mifos.org>) kirjutas kuupäeval P,
>>> 31.
>>> > > märts 2019 kell 18:59:
>>> > >
>>> > > > Hello Juhan,
>>> > > >
>>> > > > Yes, get started with the proof of concept. You'll also need to
>>> create
>>> > > > issues for the CI/CD work you're doing and probably name branches
>>> after
>>> > > the
>>> > > > issue number.
>>> > > >
>>> > > > Vishwas mentioned that a Jfrog open source license is available for
>>> > > Apache
>>> > > > Fineract. I think he's best placed to get those details though to
>>> you.
>>> > > >
>>> > > > More grease to your elbows.
>>> > > >
>>> > > > Cheers,
>>> > > > Isaac Kamga.
>>> > > >
>>> > >
>>> >
>>>
>>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Ebenezer Graham <eg...@alustudent.com>.
Hi Community / Juhan,
Nice job with the Travis CI integration. They are working nicely! In
addition, I want to suggest an idea.
Can we have an after failure procedure in the .travis.yml to make the log
output of a failed build available to Fineract developers?
As you may already know, with TravisCI, there is no way to login/ssh into a
build machine to inspect the job's log output interactively. And so for
instance, zipping and publishing rat reports, component-test and service
build logs for analysis will come in handy for a number of developers as we
venture into CI/CD.
I believe the common approach is by defining an after_failure script to
dump the logs in to log aggregator of our choosing. The major problem here
will be "where to publish the logs"
Also, I will create an issue on Jira to keep track of this suggestion.
Looking forward to your response.
*At your service,*
*Ebenezer Graham*
On Thu, 25 Apr 2019 at 15:43, Juhan Aasaru <aa...@gmail.com> wrote:
> Hey,
>
> thank you for feedback and help Vishwas and Courage.
> I have now created 30 pull requests for getting travis to build and upload
> to artifactory, all linked here ander Issue links:
> https://issues.apache.org/jira/browse/FINCN-148
> Its mostly copy-and-paste. Travis now builds all pull requests including
> the requests created by me.
>
> For identity I also changed the Dockerfile to wget the artifact from
> Artifcatory.
> I didn't add this to any other project yet (I plan to keep it a separate
> task).
>
> I hope some reviewer has a chance to go over my pull requests.
>
> Kind regards
> Juhan
>
>
>
> Kontakt Courage Angeh (<co...@gmail.com>) kirjutas kuupäeval R,
> 12. aprill 2019 kell 02:27:
>
>> Hi Juhan,
>>
>> Nice work!. The code base and documentation looks good.
>>
>> Regards,
>> Courage.
>>
>> On Thu, Apr 11, 2019 at 7:16 PM Vishwas Babu <
>> vishwas@confluxtechnologies.com> wrote:
>>
>> > +1
>> > Looks good to me
>> >
>> >
>> > Regards,
>> > Vishwas
>> >
>> >
>> >
>> > On Thu, Apr 11, 2019 at 9:13 AM Juhan Aasaru <aa...@gmail.com> wrote:
>> >
>> > > Hi!
>> > >
>> > > I have proof-of-concept ready and I have managed to build and publish
>> > > fineract-cn-identity artifacts with Travis.
>> > > All the fineract-cn-* projects that idenity depends on I made forks
>> and
>> > set
>> > > Travis to build and publish those artifacts.
>> > > Before I go over rest of the projects and create pull requests please
>> > have
>> > > a look and comment if you have time
>> > > (I think most important is to agree on artifact naming for non-develop
>> > > brannches and review changes to *.gradle files)
>> > >
>> > > The idea is that Travis builds snapshot artifacts and uploads them to
>> > > https://mifos.jfrog.io/mifos/libs-snapshot/org/apache/fineract/cn/
>> > > (I created user "travis-ci" to artifactory with upload permissions and
>> > > encrypted its password for each repository)
>> > > Travis detects branch automatically and if branch=develop (in my code
>> > > currently i have set branch=travis) then it uses version set in
>> > > build.gradle
>> > > For any other branch it sets artifact version to branchname-SNAPSHOT
>> > > If one creates a release in github then it uses tag as version and
>> > uploads
>> > > it under different repoKey,
>> > > so that it will be available here:
>> > > https://mifos.jfrog.io/mifos/libs-release/org/apache/fineract/cn/
>> > > Travis will also build all pull requests but those artifacts are not
>> > > uploaded anywhere.
>> > >
>> > > I have documented the usage and setup here:
>> > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/FINERACT/Fineract-CN+Artifactory
>> > >
>> > > Here is travis build log for Idenity project:
>> > > https://travis-ci.com/aasaru/fineract-cn-identity
>> > >
>> > > And the code changes of fineract-cn-idenity:
>> > >
>> > >
>> >
>> https://github.com/apache/fineract-cn-identity/compare/develop...aasaru:travis
>> > > All the other repos github.com/aasaru/fineract-cn-* will have similar
>> > > changes
>> > > (travis.sh will be identical everywhere and .travis.yml as well
>> (except
>> > the
>> > > encrypted password)
>> > >
>> > > Please let me know if you have any comments or if you have none then I
>> > will
>> > > create pull requests next week.
>> > >
>> > > Kind regards
>> > > Juhan
>> > >
>> > >
>> > > Kontakt Isaac Kamga (<is...@mifos.org>) kirjutas kuupäeval P,
>> 31.
>> > > märts 2019 kell 18:59:
>> > >
>> > > > Hello Juhan,
>> > > >
>> > > > Yes, get started with the proof of concept. You'll also need to
>> create
>> > > > issues for the CI/CD work you're doing and probably name branches
>> after
>> > > the
>> > > > issue number.
>> > > >
>> > > > Vishwas mentioned that a Jfrog open source license is available for
>> > > Apache
>> > > > Fineract. I think he's best placed to get those details though to
>> you.
>> > > >
>> > > > More grease to your elbows.
>> > > >
>> > > > Cheers,
>> > > > Isaac Kamga.
>> > > >
>> > >
>> >
>>
>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Juhan Aasaru <aa...@gmail.com>.
Hey,
thank you for feedback and help Vishwas and Courage.
I have now created 30 pull requests for getting travis to build and upload
to artifactory, all linked here ander Issue links:
https://issues.apache.org/jira/browse/FINCN-148
Its mostly copy-and-paste. Travis now builds all pull requests including
the requests created by me.
For identity I also changed the Dockerfile to wget the artifact from
Artifcatory.
I didn't add this to any other project yet (I plan to keep it a separate
task).
I hope some reviewer has a chance to go over my pull requests.
Kind regards
Juhan
Kontakt Courage Angeh (<co...@gmail.com>) kirjutas kuupäeval R, 12.
aprill 2019 kell 02:27:
> Hi Juhan,
>
> Nice work!. The code base and documentation looks good.
>
> Regards,
> Courage.
>
> On Thu, Apr 11, 2019 at 7:16 PM Vishwas Babu <
> vishwas@confluxtechnologies.com> wrote:
>
> > +1
> > Looks good to me
> >
> >
> > Regards,
> > Vishwas
> >
> >
> >
> > On Thu, Apr 11, 2019 at 9:13 AM Juhan Aasaru <aa...@gmail.com> wrote:
> >
> > > Hi!
> > >
> > > I have proof-of-concept ready and I have managed to build and publish
> > > fineract-cn-identity artifacts with Travis.
> > > All the fineract-cn-* projects that idenity depends on I made forks and
> > set
> > > Travis to build and publish those artifacts.
> > > Before I go over rest of the projects and create pull requests please
> > have
> > > a look and comment if you have time
> > > (I think most important is to agree on artifact naming for non-develop
> > > brannches and review changes to *.gradle files)
> > >
> > > The idea is that Travis builds snapshot artifacts and uploads them to
> > > https://mifos.jfrog.io/mifos/libs-snapshot/org/apache/fineract/cn/
> > > (I created user "travis-ci" to artifactory with upload permissions and
> > > encrypted its password for each repository)
> > > Travis detects branch automatically and if branch=develop (in my code
> > > currently i have set branch=travis) then it uses version set in
> > > build.gradle
> > > For any other branch it sets artifact version to branchname-SNAPSHOT
> > > If one creates a release in github then it uses tag as version and
> > uploads
> > > it under different repoKey,
> > > so that it will be available here:
> > > https://mifos.jfrog.io/mifos/libs-release/org/apache/fineract/cn/
> > > Travis will also build all pull requests but those artifacts are not
> > > uploaded anywhere.
> > >
> > > I have documented the usage and setup here:
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract-CN+Artifactory
> > >
> > > Here is travis build log for Idenity project:
> > > https://travis-ci.com/aasaru/fineract-cn-identity
> > >
> > > And the code changes of fineract-cn-idenity:
> > >
> > >
> >
> https://github.com/apache/fineract-cn-identity/compare/develop...aasaru:travis
> > > All the other repos github.com/aasaru/fineract-cn-* will have similar
> > > changes
> > > (travis.sh will be identical everywhere and .travis.yml as well (except
> > the
> > > encrypted password)
> > >
> > > Please let me know if you have any comments or if you have none then I
> > will
> > > create pull requests next week.
> > >
> > > Kind regards
> > > Juhan
> > >
> > >
> > > Kontakt Isaac Kamga (<is...@mifos.org>) kirjutas kuupäeval P,
> 31.
> > > märts 2019 kell 18:59:
> > >
> > > > Hello Juhan,
> > > >
> > > > Yes, get started with the proof of concept. You'll also need to
> create
> > > > issues for the CI/CD work you're doing and probably name branches
> after
> > > the
> > > > issue number.
> > > >
> > > > Vishwas mentioned that a Jfrog open source license is available for
> > > Apache
> > > > Fineract. I think he's best placed to get those details though to
> you.
> > > >
> > > > More grease to your elbows.
> > > >
> > > > Cheers,
> > > > Isaac Kamga.
> > > >
> > >
> >
>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Courage Angeh <co...@gmail.com>.
Hi Juhan,
Nice work!. The code base and documentation looks good.
Regards,
Courage.
On Thu, Apr 11, 2019 at 7:16 PM Vishwas Babu <
vishwas@confluxtechnologies.com> wrote:
> +1
> Looks good to me
>
>
> Regards,
> Vishwas
>
>
>
> On Thu, Apr 11, 2019 at 9:13 AM Juhan Aasaru <aa...@gmail.com> wrote:
>
> > Hi!
> >
> > I have proof-of-concept ready and I have managed to build and publish
> > fineract-cn-identity artifacts with Travis.
> > All the fineract-cn-* projects that idenity depends on I made forks and
> set
> > Travis to build and publish those artifacts.
> > Before I go over rest of the projects and create pull requests please
> have
> > a look and comment if you have time
> > (I think most important is to agree on artifact naming for non-develop
> > brannches and review changes to *.gradle files)
> >
> > The idea is that Travis builds snapshot artifacts and uploads them to
> > https://mifos.jfrog.io/mifos/libs-snapshot/org/apache/fineract/cn/
> > (I created user "travis-ci" to artifactory with upload permissions and
> > encrypted its password for each repository)
> > Travis detects branch automatically and if branch=develop (in my code
> > currently i have set branch=travis) then it uses version set in
> > build.gradle
> > For any other branch it sets artifact version to branchname-SNAPSHOT
> > If one creates a release in github then it uses tag as version and
> uploads
> > it under different repoKey,
> > so that it will be available here:
> > https://mifos.jfrog.io/mifos/libs-release/org/apache/fineract/cn/
> > Travis will also build all pull requests but those artifacts are not
> > uploaded anywhere.
> >
> > I have documented the usage and setup here:
> >
> >
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract-CN+Artifactory
> >
> > Here is travis build log for Idenity project:
> > https://travis-ci.com/aasaru/fineract-cn-identity
> >
> > And the code changes of fineract-cn-idenity:
> >
> >
> https://github.com/apache/fineract-cn-identity/compare/develop...aasaru:travis
> > All the other repos github.com/aasaru/fineract-cn-* will have similar
> > changes
> > (travis.sh will be identical everywhere and .travis.yml as well (except
> the
> > encrypted password)
> >
> > Please let me know if you have any comments or if you have none then I
> will
> > create pull requests next week.
> >
> > Kind regards
> > Juhan
> >
> >
> > Kontakt Isaac Kamga (<is...@mifos.org>) kirjutas kuupäeval P, 31.
> > märts 2019 kell 18:59:
> >
> > > Hello Juhan,
> > >
> > > Yes, get started with the proof of concept. You'll also need to create
> > > issues for the CI/CD work you're doing and probably name branches after
> > the
> > > issue number.
> > >
> > > Vishwas mentioned that a Jfrog open source license is available for
> > Apache
> > > Fineract. I think he's best placed to get those details though to you.
> > >
> > > More grease to your elbows.
> > >
> > > Cheers,
> > > Isaac Kamga.
> > >
> >
>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Vishwas Babu <vi...@confluxtechnologies.com>.
+1
Looks good to me
Regards,
Vishwas
On Thu, Apr 11, 2019 at 9:13 AM Juhan Aasaru <aa...@gmail.com> wrote:
> Hi!
>
> I have proof-of-concept ready and I have managed to build and publish
> fineract-cn-identity artifacts with Travis.
> All the fineract-cn-* projects that idenity depends on I made forks and set
> Travis to build and publish those artifacts.
> Before I go over rest of the projects and create pull requests please have
> a look and comment if you have time
> (I think most important is to agree on artifact naming for non-develop
> brannches and review changes to *.gradle files)
>
> The idea is that Travis builds snapshot artifacts and uploads them to
> https://mifos.jfrog.io/mifos/libs-snapshot/org/apache/fineract/cn/
> (I created user "travis-ci" to artifactory with upload permissions and
> encrypted its password for each repository)
> Travis detects branch automatically and if branch=develop (in my code
> currently i have set branch=travis) then it uses version set in
> build.gradle
> For any other branch it sets artifact version to branchname-SNAPSHOT
> If one creates a release in github then it uses tag as version and uploads
> it under different repoKey,
> so that it will be available here:
> https://mifos.jfrog.io/mifos/libs-release/org/apache/fineract/cn/
> Travis will also build all pull requests but those artifacts are not
> uploaded anywhere.
>
> I have documented the usage and setup here:
>
> https://cwiki.apache.org/confluence/display/FINERACT/Fineract-CN+Artifactory
>
> Here is travis build log for Idenity project:
> https://travis-ci.com/aasaru/fineract-cn-identity
>
> And the code changes of fineract-cn-idenity:
>
> https://github.com/apache/fineract-cn-identity/compare/develop...aasaru:travis
> All the other repos github.com/aasaru/fineract-cn-* will have similar
> changes
> (travis.sh will be identical everywhere and .travis.yml as well (except the
> encrypted password)
>
> Please let me know if you have any comments or if you have none then I will
> create pull requests next week.
>
> Kind regards
> Juhan
>
>
> Kontakt Isaac Kamga (<is...@mifos.org>) kirjutas kuupäeval P, 31.
> märts 2019 kell 18:59:
>
> > Hello Juhan,
> >
> > Yes, get started with the proof of concept. You'll also need to create
> > issues for the CI/CD work you're doing and probably name branches after
> the
> > issue number.
> >
> > Vishwas mentioned that a Jfrog open source license is available for
> Apache
> > Fineract. I think he's best placed to get those details though to you.
> >
> > More grease to your elbows.
> >
> > Cheers,
> > Isaac Kamga.
> >
>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Juhan Aasaru <aa...@gmail.com>.
Hi!
I have proof-of-concept ready and I have managed to build and publish
fineract-cn-identity artifacts with Travis.
All the fineract-cn-* projects that idenity depends on I made forks and set
Travis to build and publish those artifacts.
Before I go over rest of the projects and create pull requests please have
a look and comment if you have time
(I think most important is to agree on artifact naming for non-develop
brannches and review changes to *.gradle files)
The idea is that Travis builds snapshot artifacts and uploads them to
https://mifos.jfrog.io/mifos/libs-snapshot/org/apache/fineract/cn/
(I created user "travis-ci" to artifactory with upload permissions and
encrypted its password for each repository)
Travis detects branch automatically and if branch=develop (in my code
currently i have set branch=travis) then it uses version set in build.gradle
For any other branch it sets artifact version to branchname-SNAPSHOT
If one creates a release in github then it uses tag as version and uploads
it under different repoKey,
so that it will be available here:
https://mifos.jfrog.io/mifos/libs-release/org/apache/fineract/cn/
Travis will also build all pull requests but those artifacts are not
uploaded anywhere.
I have documented the usage and setup here:
https://cwiki.apache.org/confluence/display/FINERACT/Fineract-CN+Artifactory
Here is travis build log for Idenity project:
https://travis-ci.com/aasaru/fineract-cn-identity
And the code changes of fineract-cn-idenity:
https://github.com/apache/fineract-cn-identity/compare/develop...aasaru:travis
All the other repos github.com/aasaru/fineract-cn-* will have similar
changes
(travis.sh will be identical everywhere and .travis.yml as well (except the
encrypted password)
Please let me know if you have any comments or if you have none then I will
create pull requests next week.
Kind regards
Juhan
Kontakt Isaac Kamga (<is...@mifos.org>) kirjutas kuupäeval P, 31.
märts 2019 kell 18:59:
> Hello Juhan,
>
> Yes, get started with the proof of concept. You'll also need to create
> issues for the CI/CD work you're doing and probably name branches after the
> issue number.
>
> Vishwas mentioned that a Jfrog open source license is available for Apache
> Fineract. I think he's best placed to get those details though to you.
>
> More grease to your elbows.
>
> Cheers,
> Isaac Kamga.
>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Vishwas Babu <vi...@confluxtechnologies.com>.
Juhan,
You should have received a mail from jFrog with the login details. Please
let me know if you have any trouble logging in.
Regards,
Vishwas
On Sun, Mar 31, 2019 at 8:59 AM Isaac Kamga <is...@mifos.org> wrote:
> Hello Juhan,
>
> Yes, get started with the proof of concept. You'll also need to create
> issues for the CI/CD work you're doing and probably name branches after the
> issue number.
>
> Vishwas mentioned that a Jfrog open source license is available for Apache
> Fineract. I think he's best placed to get those details though to you.
>
> More grease to your elbows.
>
> Cheers,
> Isaac Kamga.
>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Isaac Kamga <is...@mifos.org>.
Hello Juhan,
Yes, get started with the proof of concept. You'll also need to create
issues for the CI/CD work you're doing and probably name branches after the
issue number.
Vishwas mentioned that a Jfrog open source license is available for Apache
Fineract. I think he's best placed to get those details though to you.
More grease to your elbows.
Cheers,
Isaac Kamga.
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Juhan Aasaru <aa...@gmail.com>.
Hi!
Thank you for your feedback.
I can try to set up JFrog OSS Artifactory for Fineract CN.
I did some research. According to blog post [1] it should be possible to
build with Travis-CI and upload
snapshots to Jfrog OSS [2] which is free for open source projects. And oss
is meant for snapshots.
My first proof of concept would be to build poject fineract-cn-lang with
travis, get it to upload built snapshot to JFrog oss
and then configure fineract-cn-api (that depends on fineract-cn-lang) to
pull snapshots from jfrog oss and then
try to get travis build and publish fineract-cn-api snapshot artifacts to
OSS as well.
Isaac and Vishwas, could you please help me with getting access to JFrog
OSS.
If you could grant my github user (aasaru) temporarily access to these two
fineract projects (lang and api) then I would create
a separate branch "travis-ci-jfrong-oss" to both of the repos (and work
there). I don't think I would manage to set this
up only using forks (publishing to artifactory would be diffictult as it is
only for hand picked open source projects).
Kind regards
Juhan
[1]
http://grailsblog.objectcomputing.com/posts/2016/10/03/how-to-use-travis-to-build-and-deploy-your-plugin.html
[2] https://oss.jfrog.org/webapp/#/home
Kontakt Vishwas Babu (<vi...@confluxtechnologies.com>) kirjutas kuupäeval
R, 29. märts 2019 kell 00:19:
> 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 <aa...@gmail.com> 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
> >
>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Vishwas Babu <vi...@confluxtechnologies.com>.
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 <aa...@gmail.com> 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
>
Re: Building and serving fineract-cn artifacts with jitpack.io
Posted by Isaac Kamga <is...@mifos.org>.
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 <aa...@gmail.com> 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
>