[
https://issues.apache.org/jira/browse/FINERACT-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17210213#comment-17210213
]
Aleksandar Vidakovic edited comment on FINERACT-1171 at 10/8/20, 1:42 PM:
--------------------------------------------------------------------------
[~ptuomola] happy that you like it :):
# concerning Eclipse: true... I should have mentioned it for my things to do,
just forgot; valid point; will take a look at this today and verify if it works
as intended
# the Renovate bot is really a nice tool; I guess we have to try how this
works out; would definitely like to keep the bot and the BOMs... but let's see
then which one saves us more work
# concerning jgitver: the short answer here is yes, it does something sensible
in forks, branches etc. But... for that we should add the current Git hash to
the version number (think of it as kind of "SNAPSHOT", just globally unique).
With that you really get meaningful builds in the sense that you can pinpoint
the binary artifacts to a specific commit in the Git history. The only reason
why I left it out for now was the way how I copy the Swagger file from
fineract-provider to fineract-client; I'd like to reverse the build order of
those (didn't succeed yet) then we can enable the Git hashes again (and remove
the Git managed Swagger file in fineract-client). The problem with the Git hash
in the version scheme and the Swagger file copy is that on each build the file
is copied with a new version number to fineract-client... which you have to
commit... which in turn generates a new version number... and so on ;) ; but
again, I'll find a solution and this issue will go away. Another reason we
might want to have those Git hashes in the version numbers (actually only in
all non-release branches and probably also not in master): when we create
Docker images based on that automatic version and let's say we want to publish
- kind of - snapshot images on Docker registries (e. g. on AWS ECR) then
sometimes we are required to provide unique version numbers for each publish
(default policy on ECR)... and with the Git hashes we get that for free...
which will allow us to publish ready to use Docker images from the Github
Action build. And: in case a user/client/admin "finds" one of those artifacts
(jars, wars) or Docker image in their deployments they can easily lookup the
exact history and what went into the version they are currently using... even
if they use pre-release builds... should come in handy when you have to track
down issues.
was (Author: aleks):
[~ptuomola] :
# concerning Eclipse: true... I should have mentioned it for my things to do,
just forgot; valid point; will take a look at this today and verify if it works
as intended
# the Renovate bot is really a nice tool; I guess we have to try how this
works out; would definitely like to keep the bot and the BOMs.
# concerning jgitver: the short answer here is yes, it does something sensible
in forks, branches etc. But... for that we should add the current Git hash to
the version number (think of it as kind of "SNAPSHOT", just globally unique).
With that you really get meaningful builds in the sense that you can pinpoint
the binary artifacts to a specific commit in the Git history. The only reason
why I left it out for now was the way how I copy the Swagger file from
fineract-provider to fineract-client; I'd like to reverse the build order of
those (didn't succeed yet) then we can enable the Git hashes again (and remove
the Git managed Swagger file in fineract-client). The problem with the Git hash
in the version scheme and the Swagger file copy is that on each build the file
is copied with a new version number to fineract-client... which you have to
commit... which in turn generates a new version number... and so on ;) ; but
again, I'll find a solution and this issue will go away. Another reason we
might want to have those Git hashes in the version numbers (actually only in
all non-release branches and probably also not in master): when we create
Docker images based on that automatic version and let's say we want to publish
- kind of - snapshot images on Docker registries (e. g. on AWS ECR) then
sometimes we are required to provide unique version numbers for each publish
(default policy on ECR)... and with the Git hashes we get that for free...
which will allow us to publish ready to use Docker images from the Github
Action build. And: in case a user/client/admin "finds" one of those artifacts
(jars, wars) or Docker image in their deployments they can easily lookup the
exact history and what went into the version they are currently using... even
if they use pre-release builds... should come in handy when you have to track
down issues.
> Multi-module configuration for Gradle
> -------------------------------------
>
> Key: FINERACT-1171
> URL: https://issues.apache.org/jira/browse/FINERACT-1171
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Build
> Affects Versions: 1.5.0
> Reporter: Aleksandar Vidakovic
> Assignee: Aleksandar Vidakovic
> Priority: Major
> Fix For: 1.5.0
>
>
> Use the build.gradle file in the root folder rather than in fineract-provider
> to import the project in IDEs.
> Note: this will force everyone to re-import the project in their IDEs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
