[
https://issues.apache.org/jira/browse/BIGTOP-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349478#comment-14349478
]
Nate DAmico commented on BIGTOP-1494:
-------------------------------------
Github/bitbucket.., or internal git. For instance, enterprise Foo, is running
bigtop internally, and maintain their own src/build of zookeeper b/c they have
some tweak or compilation variant they want/need. They could use bigtop but
tell it to pull from repo xyz, and either bake the auth/creds in or optionally
have bigtop use specific ones denoted. Not sure how relevant or the 0.5% of
shops that would want but was thinking through other repo params that might be
necessary
> Introduce Groovy DSL to replace bigtop.mk in Gradle build
> ----------------------------------------------------------
>
> Key: BIGTOP-1494
> URL: https://issues.apache.org/jira/browse/BIGTOP-1494
> Project: Bigtop
> Issue Type: Bug
> Components: build
> Affects Versions: 0.8.0
> Reporter: jay vyas
> Assignee: Konstantin Boudnik
> Fix For: 0.9.0
>
>
> Seems confusing to have a {{.mk}} file which is mostly just a bunch of
> variable declarations, which is then parsed as a CSV, simply for the sake of
> guiding the {{packages.gradle}} file .
> Can we be more idiomatic to gradle and either eliminate {{bigtop.mk}} by
> making it into a native gradle data structure (its really just an array, and
> we can declare in gradle.settings) , so that the {{readBOM}} function is
> easier to follow ?
> I think it is an entry point to understanding bigtop's build system so we
> should try to simplify it as much as possible to make it maximally easy for
> people to understand how bigtop's gradle packaging system works.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
