Forgot to copy the list... -------- Forwarded Message -------- Subject: Re: Getting started on Fineract CN Date: Mon, 26 Feb 2018 16:38:56 -0700 From: Phil Steitz <phil.ste...@gmail.com> To: Myrle Krantz <my...@apache.org>
On 2/26/18 2:01 PM, Myrle Krantz wrote: > Hey Phil, > > On Mon, Feb 26, 2018 at 8:13 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >> We should replace the source headers with standard headers. The SGA >> entitles us to do that. We *can* include copyright notices citing >> the original authors in NOTICE.txt, but should only do so if that >> has been requested by the grantors. > Thank you for the information. I'll do a simple replace, like you suggest. > >> I just did that. To make this easier, I created a list of repos >> based on the github query you posted. I use bash one-liners to do >> the clones, pulls and (attempted) builds. For example, the build >> locally one does this: >> >> cat $1 | while read in; do cd "$in"; echo "updating and publishing >> $in"; git pull; chmod +x gradlew; ./gradlew PublishToMavenRepo; cd >> ..; done >> >> where the command line arg is the file with just the repo names in >> it. The problem I am now having is that the order of the repos in >> the file is just random and there appears to be a required build >> order. I am pretty new to gradle, but in maven the reactor would >> take care of figuring that out. I will try to figure it out and fix >> the order of the file, clean up the scripts and post them >> somewhere. Or someone who actually knows gradle can create >> something like a fineract-cn-parent thingy whose build does all of >> this. Or I learn that this is all easily done using some gradle >> commands that I don't know :) > We have a script like this in the demo-server project. You can find > it under fineract-cn-demo-server/scripts Doh! I should have seen that. Does pretty much exactly what I was fumbling with. > To be honest I don't use it; > I work from my own knowledge of the dependencies, but I know it's > ridiculous to ask that of anyone else. We definitely need to improve > this area. > > Other people have complained that there things missing or that it > doesn't work under certain OSes, or that it doesn't work consistently. The key is to get people directed to whatever we have in place and improve it over time. Once I have fully succeeded, I will submit a doco patch that points people in the right direction to get started. > > I personally would prefer a gradle parent project like the one you > describe. But ultimately I'd like for everything to be in an > artifactory so that in most cases, you only have to build the projects > you are making changes to. We have a bit of work to do before we get > there though. I don't know gradle well enough to know how much work that would be, but no time like the present to learn something new :) > > In the meantime, I think several people would very much appreciate any > improvements you might offer for the scripts. > > Once I've gotten the headers updated, and the packages straightened > out, I'd like to start putting things in an artifactory. I haven't > gone exploring to figure out how other Apache projects work with > unreleased build-snapshots though, which we'll need for this. Do you > know of any other projects at Apache which upload build-snapshots of > unreleased code to an artifactory? Yes, lots of projects use https://repository.apache.org/snapshots/ There is an argument though that if it can be easily greased, the pull-and-publish locally model may be just as good. Once we have releases, we can move to depending on released artifacts. I guess it depends on how much breakage happens / how current you need your snaps to be. Phil > > Best Regards, > Myrle >
