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 (<[email protected]>) 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 <[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